I know that's not the fashion currently, but it's probably one of the most valuable things to me.
We don’t want dead languages, look at Java. It was stagnant for a long time, but has now shifted to a better delivery methodology of new language features. Rust is the same and continues to improve. Continues to make things easier and better to use without giving up its speed and low overhead goals.
If you're shipping code and modified code, you care about the language in which you can make those modifications. A frozen language means that either those modifications are harder (because potential improvements to the language are ignored) or they require writing components in an entirely new language and figuring out interop.
(If you're not shipping modified code, then you don't care if the language changes after you ship, anyway. You shipped, and then you're done.)
I don't agree that it's harder. What is definitely harder is not being able to ship bug-fixes or modifications without ripping everything up because the language has moved on since your last release. And that is very common when developing for, as an example, iOS, since Swift is a fast-moving language that doesn't maintain backwards compatibility. The benefits of having some new language feature in Swift are far outweighed by the downside of existing codebases being invalidated. The various languages in the Javascript family suffer from this as well. The Python 2 -> Python 3 debacle was another example of this.
I have dusted off 20 year old Java code which compiled and ran just fine just fine. That is extraordinarily valuable to me, and requires a lot of discipline by the language maintainers. In fact, the new faster pace of Java iteration could be its downfall, time will tell.
A last note: how many language features from the past 20 years really matter? How many really speed up development, improve maintainability, etc. I would say that there are very few. In fact, perhaps the only one that passes that bar might be async/await type threading advancements.
People move to Python 3 not because Python 2 is unusable - it was perfectly usable five years ago and the bits haven't disappeared from our world - but because there's lots of small things that make development easier, faster, more pleasant, and more robust. I don't think there's any single feature you can point to, but there have certainly been countless little things where, when I work on a Python 2 codebase these days, I say "I wish this were Python 3."
Anyway, Rust in particular committed to indefinite backwards compatibility when they released 1.0, and the "epochs" system has been a good (post-1.0) implementation of this. They realized they wanted some keywords that they didn't reserve, some syntax that they didn't define, etc., so they said there are two epochs, 2015 and 2018. The compiler handles both, but the newer syntax only works in the 2018 epoch. If you have code that was written pre-2018, it'll keep working indefinitely, even with new compilers.
Languages are the same. Decisions in the past may be discovered to be incorrect in the future. Some features make the language far easier to work with and built better more stable software.
In Rust there are some big ones. ?, For easier returns from functions when errors are encountered, this simplified my code, made it easier to read. async/await, vastly simplifies Future based code, based on my own experience I believe there was a 30% reduction in code when I converted old hand written Futures to the new model. These are big awesome features in Rust, that most people who use them find to be great improvements for productivity.
Your attempt at an analogy is off, because neither wood nor vinyl are living things. I think if we turn to other engineering fields it’s more obvious. For example, batteries. We’ve had batteries since nearly the time that electricity was discovered. If they did not improve over the years, would we be able to build high-performance log-range cars with them? E-bikes with them?
Or something else, hammers are fine for nailing things, but nail-guns are amazing. Have you ever seen someone lay top nail floors with a nail-gun? I have, and my jaw hit the floor as I watched how fast they were.
I want my languages to be the same. Improve things that make the language better at working in difficult engineering spaces (for us that might be embedded), and improve it to make it more productive so I can build better software faster.
I am skeptical that all language features make code better. It shifts the complexity from the code to the programmer. In order to read a piece of code, I need to potentially keep up with all of the new language features, which is a huge burden in C++.
Those new features also have a tendency for complicating otherwise simple things. Like all of the edge cases that arise from objects with moving and exceptions. Sure the code might look simpler, but there is a lot more going on in the background you have to keep track of.
When I write C++ now, it is typically as C with a few constexprs and templates thrown in. I try to avoid most of the new features because they just distract me from writing code that works.
I program to solve problems. Changes in a language or worse, "how it is done" mean that I must keep up with something else in addition to solving the problems before me. Waves of increasing syntactic sugar in a language begin to look like layers of frippery and frosting, and I can only remember that "fashion is a form of ugliness so intolerable that we have to alter it every six months." I do not want to look at some bits of upper-row "executable line noise" that is somehow called syntactic sugar and try to have to mentally project what surface lies under that frosting.
What I want is to be able to look at ten year old code and it immediately be working and understandable. I don't want it to be out to style or "uncool" or to even have to think about these things.
By all means, fix bugs. Add libraries as new formats, protocols, and technologies emerge. Huge mistakes can be corrected in rare major version updates, which may have to count as actual forks in the language. When I first looked at Python, somewhere around 2004 or 2005 if I had to guess, I remember seeing that whole floor division bit and thinking, "Yeah, they're going to have to change that eventually and digging in their heels on that one was foolish." That's a rare exception, and it counts in the "why did this make it to 2.x?" category.
I feel a bit lonely in this, but I just cannot seem to embrace the churn.
It's that sort of thing that has pushed me in the direction of, if there's no other pressing reason to adopt a language, selecting those which have been stable for a while.