Yes, that does seem to be the cycle. I think the problem is that approaching a mature language is very difficult, and requires a lot of patience and dedication to learn. I've been writing C++ for over 10 years, and for most of that time, everything I've learned has demonstrated to me that there are several more things that I hadn't realised that I didn't understand. Now that I'm writing a C++ language support library to make GCC work with our platform, I feel that I've finally reached a tipping point, understanding multiple inheritance, RTTI and exception handling in some depth.
When a developer doesn't understand a complex feature of a language, and can get by with a simpler approach, it is very easy for them to believe that the complex feature is just clutter. (And vendors exploit this perception to promote their proprietary languages, which allow you to write impressive demo code very quickly, but aren't up to the job of fleshing out and maintaining a full application).
As programmers set out with a new, simple programming language, they start to understand the problems which the complex feature addressed, and start demanding that the feature be added to their simple language. Eventually the simple language evolves into something that the next generation of programmers turn away from in horror.
So what's the solution?
Well a good start would be if programmers spent more time learning, particularly learning about programming in general, rather than programming with a particular language. I find it saddening when some developers criticise C++ saying that Java and C# are "more object-oriented than C++", demonstrating that they don't understand (i) the difference between supporting a design and programming paradigm on the one hand, and forcing programmers to put all data and functions into syntactic structures labelled "class" on the other, and (ii) that object orientation is only one paradigm which is eminently suitable for many problems, but is not ideal or is even irrelevant to others.
Another would be if skilled developers were given the ability to choose the technology suitable to the problem to be solved, rather than being forced by managers to use whatever whizzy product some vendor has just convinced them will magically create a solution to all their business problems just with a few mouse clicks performed by people with no knowledge of software development.
I've seen software development work well and work badly over the years. Where it's gone well, it's been due to a good team of skilled developers, where the most experienced ones mentor the less experienced; and where the immediate management have prevented higher management from interfering with day-to-day activities, but have made sure that the development team are focussing on solving the business goals (without trying to force them to do so in any particular way).