a worthwhile replacement for Perl 5.

I still don't get all this endeavour to re-write P5 in P6. P5 is perfectly embeddable.

Just embed perl5xx.dll/.so into the P6 compiler and provide:

1. P6 built-in(s) to access p5 subroutines:

   Say something like:

   use P5 qw[ LWP::Simple ];
   ...
   
   my $url :String = <...some P6 source>;
   my $content = p5call( "LWP::Simple::get( $url )" );
   [download]

   ).
2. P6 proxies for P5 objects:

   Say:

   use P5 qw[  DBI DBD::Pg ];
   
   ...
   my $dbi = P5Object( "DBI->connect( $dataSource, $userName, $userAuth, 
   +\%attrs" ); );
   my $sth = $dbi->prepare( 'SOME SQL HERE' );
   ...
   [download]

Full compatibility at a stroke, and full P5 performance (within the p5 code), and a small hit through the thunking layer.

How hard could it be to write the thunking layer? (It's gotta be easier than recreating P5 + XS + everything else.)

I effectively do exactly this in my 15-line Perl5 REPL.

How hard could it be to write the thunking layer?

Keep in mind the current mindset is that everything has to be portable across all of the (hypothetical) backends that Rakudo (hypothetically) supports, so writing a thin embedding layer in C won't do. You have to write it in NQP and then hope that the backend allows you to invoke C functions in an efficient way. That's C for Parrot, JNI for the JVM, something like P/Invoke for the CLR, wishful thinking for v8, and magic unicorn fairy dust for MoarVM.

It's gotta be easier than recreating P5 + XS + everything else.

If P6 is optimized for -Ofun, then plumbing and maintenance and packaging and all of the other pieces of finish work that aren't glamorous must not be fun.

lend me some of your dust ...

P5 is perfectly embeddable. ...

The architecture of what I called Mixing P6 and Perl 5 with XS in my recent Perl 6 <-> Perl 5 bridges comment is pretty much as you describe. (Though, aiui, it'll take more than 15 lines of code.)

the celebrity tell-all of the Perl-6 cult