I read the link http://blogs.perl.org/users/leon_timmermans/2020/06/not-quite-getting-better-yet.html posted by k-mx and then this comment under it:

And if there were a binary /usr/bin/perl7 which was like /usr/bin/perl -M7, would that be OK?

"Nature abhors a vacuum". I should add: and Nature works its way without asking anyone or caring about anyone's plans or feelings. It's also true that a lot of the side-effects of Nature's ways can not be anticipated even by today's science: it's a chaotic or too complex a system sometimes. So, I hope those who are in charge of this know their limitations *in predicting* the side-effects.

Fair enough, the cited comment's scenario is closer to aliasing than having multiple, versioned (system-wide) binaries. But who can say that sooner or later the alias does not become a distinct binary because that's simply convenient. And who would say that, as people subconsciously love stereotypes, the alias becomes versioned binary in people's minds and soon the label sticks. And it affects decisions in board-rooms.

Here is my suggestion for an experiment: when there is a working prototype for these changes, clone CPAN and test all modules with it. Note the % of failures, that's one metric. Then pick *at random* a relatively small number of modules and try to "fix" them. Categorise each fix in "easy", "hard", "impossible" etc. These numbers should then be multiplied by 10x to see the effect on real code "out there".

Just a few thoughts from a non-professional Perl user who admits I would prefer to see Perl first conquering Bioinformatics (it can surely be done by just more *man-power on existing efforts), trying to act as a scripting glue for R - oh boy who wouldn't like to have the power of R from Perl rather than ... R - and AI algorithms in general. It requires user-friendly, easier way to interface with existing binary (super-fast, already tested) libraries, by XS being majorly upgraded for ease-of-use and Inline::* work perfectly (see my futile attempt to interface with opencv - which is state-of-the-art - because of ... eehmmm ... internal variables name conflicts: Inline::CPP + OpenCV = problems). I could also add making PDL more accessible, why can't its use be transparent in Perl??? Now, for me, these are projects worth taking on and let signatures wait a bit longer.

bw, bliako