What happened to Perl 7?

Maybe that's less obvious than you think it is. Once we accept that change is inevitable (which you seem to) then there's actually some reason to think we should prefer a somewhat steady tempo of change, not necessarily the minimum possible delta.

One reason is rust. Not the language, the problem. If you don't exercise freedom of motion it rusts into place without you realising. This is why TLS 1.3 is spelled SSL 0x0303 on the wire, first TLS needed to pretend to just be SSL 3 (hence TLS 1.0 was SSL 3.1, TLS 1.2 wsa SSL 3.3 aka 0x0303) and then even that rusted into place so TLS 1.3 pretends to be TLS 1.2 or else it won't work. So long as Perl ships new versions with new syntactical features every year or two, the propensity for things to rust into place can be curtailed, but imagine if Perl today and Perl from 2008 had the exact same syntax, by now some software would expect and require that syntax. New Perl would find that introducing features, even much needed and long awaited features, tripped this rusted into place hazard despite the supposed promise to be able to exercise this option. Ouch. You may have experienced something similar with muscle tone if you had "stay at home" restrictions during the pandemic.

Also, a steady pace of change means that tooling and culture adapts properly. If the last substantive change to Perl syntax had been in 2008, what's the chance automated testing catches syntax errors related to a new change made tomorrow? Approximately zero. But if such changes happen about every 18 months on average there's a good chance somebody actually wrote a test by now. Likewise if the last change was 2008 people who expect to be warned might not realise they weren't tracking this any more. People forget how the process works. If there are on average two features proposed every year, experienced users know how to read a proposed change, where to debate it, stuff like that. The community is prepared for, and equipped to handle change, because it's just routine.

Perl has been exceptional at backward compatibility for many years. I have code I wrote in 1999 that is still running with no changes whatsoever. Given that, I'm happy to extend the benefit of the doubt and assume that this work will be done with the usual amount of care and deliberation, and I'm happy that they're working their way through the backlog of experimental features that were added to the language and then never resolved one way or the other.

Look, I've been there. I know that changes cause breakage, and I know that you can stop things from breaking if you stop making changes. The problem is, that's a short-term solution at best. For a few weeks or months, this can be highly effective:

* You had a bad week, you're all out of error budget, and you need some time to recover your SLO.
* Your company is having a big presentation or other event, and it would be really embarrassing to have an outage right at this moment.
* It's the holidays, and you really don't want to be stuck troubleshooting a production issue from your parents' house, while your great-but-technologically-illiterate uncle is trying to sell some cryptocurrency scam to your second cousin downstairs, when you would otherwise be able to prevent that transaction from taking place.

The problem is that this is not sustainable in the long run. You can't just freeze prod forever. The world is going to move on, with or without you. Eventually, you will need to change prod, and if it's been frozen for the past three years, then you are basically screwed, because you'll have to completely rebuild and redeploy absolutely everything, and make a massive change all at once. Some software won't exist anymore. Some software will exist, but will no longer be meaningfully maintained. Every piece of your technology stack is moving at a different speed, and you'll have to redo all of your version mix-and-matching from scratch. This is much, much riskier than smaller, incremental changes on a more frequent basis.

A language that barely changes is not a good thing. It's a liability. Eventually, developers will tire of working in that language, because it is missing features relative to other languages, and some of them will stop maintaining libraries and other stuff that you (probably unknowingly) depend on. Or they will get old and die/retire, and nobody will be interested in picking up the work, so it will go unmaintained by default. It's the https://xkcd.com/2347/ problem, but on a language-wide scale.