But, as long as the use VERSION line at the top of the file matches the version of the Perl language that the author meant, perl5.40.0 will run the code exactly as expected.
@book: This simply is not true.
@briandfoy: You are, of course, absolutely right: I was lying when I said feature was magical. 😅
I noted it myself, when I mentioned the autoderef feature. Not every new Perl feature is guarded by a feature (see Syntax::Construct for an extensive list).
In both our examples, though, the troublesome construction was experimental when it was introduced, and it was removed without having ever left the experimental state. I'm not convinced that code that uses experimental constructs falls under the definition of "sensibly-written" (as written by the 2021-2022 PSC in What happened to Perl 7?).
Nowadays, p5p would not introduce a change of meaning or behaviour in valid syntax without a feature guard (for an example, see the bitwise feature, which changed the meaning of the binary operators). See also how the removal of deprecated features is handled, most recently with the apostrophe_as_package_separator feature.
We're aiming for a future where most of the old ("sensibly-written") code will continue to work, untouched, with the latest perl, while everyone can write better Perl by pointedly picking the best use VERSION; line for their use case.
My message was driven by my enthusiasm for use VERSION itself. No matter if this PPC goes through or not, we want to make use VERSION the staple of modern Perl code. Yes, Perl is incredibly backwards-compatible. As we've seen, though, that's not always 100% foolproof. use VERSION is still the best hint a programmer can give to their language interpreter/compiler to ensure everything will work as expected, for as long as possible.
One of the points of this PPC (besides "Perl 5 is Perl" and "there is no successor to Perl"), is that use 42; is much more readable (and less error-prone) than use v5.42; or use 5.042;.