I thought perhaps you might like to hear my somewhat unique perspective, although definitely not saying anything others haven't already said. My perspective comes from my three hats, as a perl hobbyist and CPAN author, the maintainer of /usr/bin/perl in OpenBSD, and as someone who has written perl professionally for just short of ten years (the fifteen before that I wrote more and more perl as a sysadmin).
Overall, I think the plan is excellent and hope it mostly moves forward. There's only one tiny issue that might keep me from coming along for the ride.
tl;dr: if the default, without concious indication of something else, for bin/perl is anything but a "best effort at perl5" I believe I, and many other people will be stuck on perl5 forever and never be able to use v7, or v8, or anything later.
First, I should probably explain what I mean by a "best effort perl5". It is the thing we have gotten from perl on code without "use v5;" specified, likely since perl 5 was first released. Most things work, strict and warnings pragmas are disabled, and sometimes things get deprecated and removed. For example, for my $x qw( a b c ) {} works find up to v5.12, but warns in v5.14/v5.16, and in perl 5.18 and later is fatal. So, specific syntax gets removed with appropriate bikeshedding over how much of the CPAN and "darkpan" it will break. I'm sure folks can come up with their own examples, for example rjbs mentioned support for arybase. I can deal with this slow change to fix problematic code, enabling "use strict" or "no bareword::filehandles" by default? Those are a step too far without a "use vX" declaration.
The slow reduction of "best effort perl5" to supporting less and less of the long tail of all possible perl5 code is something I would be able to deal with, but I don't think I'll be able to upgrade to a version of perl with a hard line that refuses to run code where the only obstacle is inserting "use v5" or "no strict" into it. Based on listening to some folks who work in the core talk, I believe that the amount of things that will be removed from this "best effort perl5" will actually end up in fewer changes than what we've had since perl v5.10, since it will really only be things that are too hard to in core without removing or changing that feature.
When wearing my hobbyist hat, this change wouldn't be much of an issue, I could mostly fix code that I write and whatnot and if there is some magic solution adding that to any CPAN modules I may install, I'm mostly OK.
Unfortunately, I have been fairly well convinced that there are swaths of the CPAN that will remain useful for a long time without having a correct way of adding that "use v5" to them.
Putting on my OpenBSD hat however, there are likely places where this is not OK, and why I would be stuck with perl 5.34.x forever. The specific example that comes to mind is that I know some folks do interoperability testing between different versions of LibreSSL and OpenSSL. There are bits of perl that exist in those old releases that can't have the line added easily, especially by folks who may not know perl and would only know that "perl broke it" but have no solution for fixing it unless google comes up with something for them to paste in.
The example code I mean, which has been with OpenSSL for a long time, would not compile under use strict or no bareword::filehandles and possibly not under some of the other proposed default pragmas.
- https://github.com/openbsd/src/blob/master/lib/libcrypto/x86_64cpuid.pl
- https://github.com/openssl/openssl/blob/master/crypto/x86_64cpuid.pl
There are likely thousands of scripts written by the previous sysadmin who knew just enough perl to make it work that are in a similar condition, and the people left to fix it would just know that "perl broke their stuff", in my opinion, for no good reason.
Wearing my work hat, I can't say anything official, but again, unless the CPAN issue is magically solved, I don't know how we'd ever be able to move to perl v8, and with the bugfix support cycle for perl v5 appearing like it would outlast the support cycle for perl v7 we would be hard pressed to invest the time to upgrade, and I'd really like to be able to.
Although many folks have already said it better, this is the way I would like to see it work, although I have not considered nearly as many possibilities as other people and so may convince me to change my mind on some details.
The most important is that without some other indicator, it would be as if there was an implicit "use v5" in the scope.
I think there could be multiple ways to provide that indicator, but I agree with many other folks that adding "use vX" to the top of the file is not "too much" or too large a hurdle to get the semantics you expect your code to run under. I don't mind if someone decides to use "PERL_DEFAULT_REVISION=8" or perl notices the #! has "perl8" in it, or that $^X ends in qr/perl8[^/]*$/ in those cases maybe choose a different default when no other exists. Other people have different preferences on what these indicators should be and I can see arguments for several options.
As Exodist said so well, I would not mind at all if there was a non-fatal warning of some sort if the "top level" code didn't include a "use vX" line in order to help new perl programmers learn some best practices. To that end, as suggested by someone else, "use strict" should appease this warning as if "use v5" had been specified as well. A compile time and environment variable to disable it would bonuses. I think this one item would address the issues with people copying and pasting code they don't understand, and I think it would do a better job of it than defaulting to "current revision semantics".
One last item that I think is important is what I think "use v7.1.2" should mean. Well, I think it should require perl semantics >= v7.1.2 and < v8. That means, for example, "use feature 'signatures'" could change meaning under "use v7" vs "use v8" and not break things, suddenly there are versioned features "for free". These "lower" versions would have to be provided on a "best effort" basis as I described above for a "best effort perl5".
I don't think there's anything in that example LibreSSL script linked above that would ever have support removed from the perl core codebase, so I don't understand why refusing to run that script to be able to avoid saying "use v8" is worthwhile trade. Especially when adding it has other benefits such as being able to change semantics under "use v10" or "use v42" and not break things that say "use v7" and make static analysers lives easier.