From the perspective of a manager who is looking only at the feature lists, what is gained by that change? The "after" feature list looks just like the "before" feature list.

Sure, but why should anyone care what a really bad manager thinks? If we're going to chase the lemon market of terrible management, we're not going to get what we want.

Perl developers can jump to other languages much more easily, and breaking backwards compatibility to the point of needing significant rewrites has a much lower threshold for those rewrites to go to some other language if there is the slightest hint that it could happen again.

Ah, but from the perspective of a manager who is looking only at the feature lists, what is gained by that rewrite to some other language? The after feature list looks just like the before feature list!

I think your argument here wants it both ways.

Accordingly, I argue that backwards compatibility must not be broken without very, very, very good reasons — and the advice in PBP does not meet that threshold for a language that famously touts TIMTOWTDI.

There aren't very many people arguing seriously that backwards compatibility should be broken willy-nilly, but there seem to be several people arguing that other people are arguing that. That makes it difficult for me to take this argument seriously.

My argument is that backwards compatibility is largely a good thing, but it's less important than:

• Improving the default experience for new programmers
• Fixing bugs and security flaws
• Adding long-missing features

The argument in favor of maintaining strict backwards compatibility has lost (. in @INC by default, hash randomization, do &sub syntax, pseudohashes, unescaped { in regular expressions, mandatory parentheses around quoted lists in iterations), and it's prioritizing use cases that neither contribute to Perl development nor have a coherent use case.

I'll expand on the latter. What do we know about a project that's still deployed on Perl 5.6.1? We know:

• They're not using much of the CPAN
• They're not particularly interested in new Perl language features
• They don't care about support from p5p or distributions
• They don't care about security
• If they're investing in their code, they're not considering any external factors as important

What benefit is there in releasing a Perl 5.34 designed to support them that they will not update to (which we know because they haven't updated to 5.8.0, 5.8.1, 5.8.2, 5.8.3, et al)?

They have chosen their support burden—lack of community support, lack of security features, backporting patches they want, dwindling OS and compiler toolchain support—so why put a greater support burden on people who actively do contribute to the language and the language ecosystem?