Since 'perl5' and 'perl6' have dropped the concept of bytecode generation

Aiui it is, or would be, a monumental (I think that's an understatement) social and technical task to bring bytecode, and bytecode discipline, to the current Perl 5 compiler.

But the story is different for Parrot. And different again for Perl 6. And different again for Perl 5 in the light of Perl 6.

Parrot is a tough call. As others have said, bytecode stability was part of the original plan. It doesn't have that now, but that doesn't mean it couldn't, and won't ever. Otoh, to say they have more pressing concerns, and lack of tuits, is an understatement. Unless you are confident you could live for a few years without oxygen if you had to, I recommend you don't hold your breath waiting.

Perl 6 also has more pressing concerns, and also has less resources than it needs, but it's a much more reasonable proposition regarding generation of bytecode and discipline to keep it forward compatible as they add or change opcodes.

There are several Perl 6 compilers that generate bytecode. In particular, Niecza is pretty advanced and currently generates CLR bytecode and Rakudo is also pretty advanced and currently compiles down to Parrot bytecode. Aiui both these compilers are likely to be portable across different bytecode backends soonish; perhaps one will even manage that this year.

And a few days ago someone spotted Larry Wall working on a Perl 5 parser written in Perl 6, something that's gotta be way easier than working on the current Perl 5 compiler...