Perl5 Perl6 forking

What's "Perl5 Perl6 forking"? The rest of your comment made more sense to me so I'll focus on that in what follows.

Is there any way to ensure a switch in Perl 6 so you can choose between languages?

About 15 years ago Larry wrote that "Perl 6 must assume it is being fed Perl 5 code until it knows otherwise". The current Rakudo Perl 6 compiler does not comply with this "speculation" but that's probably because the situation has changed from what was perhaps expected back then: the Rakudo Perl 6 compiler goes by the name `perl6`, not `perl`, which instantly eliminates many of the potential accidental wrong language execution scenarios due to there being two Perls.

Continuing, Larry wrote "We ... have to figure out how Perl 6 main programs should distinguish themselves from Perl 5 (with a "use 6.0" maybe?)".

The syntax has ended up being `use v6.c;` or `use v6.d.PREVIEW;` etc. A `use 5....` or `use v5...` fed to Rakudo yields a "no such routine `use`" compile time error.

Larry also noted that "If you go out to CPAN and look at every single module out there, what do you see at the top? Answer: a "package" declaration. ... I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code.".

But fast forward to today and instead of Rakudo using a heuristic to detect which language a module is written in, the module's language must be explicitly specified in its `use` statement if it's not Perl 6, eg:

use v6.c;
use Mojo::UserAgent:from<Perl5>;
[download]

Once long ago, we used the top of the file to point the script at the executable.

Yes, a shebang could be another way for a compiler to decide what language it's dealing with.

Can we have Perl6 provide something like this to preserve legacy code.

I am sure that Perl 6 will deal properly with existing Perl 5 code but please note that Perl 5 code is not, in the general case, legacy code. (Asked recently if "Perl 6 will replace Perl 5" Larry answered, quite sincerely I think, "probably, in about 40 years or so.")

It would also be nice for CPAN modules to provide a fork so we can keep alive old stable code.

Again, Perl 5 code and CPAN modules are staying right where they are and they are not at risk.

There's talk of putting Perl 6 modules (by which I mean modules written in Perl 6 code, not modules with Perl 6 in their name) on CPAN. But CPAN (or maybe PAUSE) doesn't currently support the Perl 6 notion of having module forks (modules with the same name but written by different authors) so it's going to take time before Perl 6 modules start appearing on CPAN in bulk -- if they ever do.

Regardless, those maintaining CPAN are not going to allow Perl 6 to cause disruption.