A Perl REPL would be very nice, agreed, but I do not think that that would break much code, especially if input-dependent: present REPL if STDIN is a terminal, read program if STDIN is a pipe or file.
I do not know if retiring XS is as good an idea as it sounds — XS contributes significantly to perl's performance with some extensions.
I am not sure that there are any usable sigil characters left in ASCII, although caret might be usable if it can be disambiguated from bitwise-XOR. Ampersand is both code sigil and bitwise-AND, so this might be workable.
Generating webassembly sounds like a role for a B:: module.
A Perl REPL would be very nice, agreed, but I do not think that that would break much code,
It is possible you're right, and that's preferable. But: if I were presented with a first-class repl with completion and introspection, and also acts as an LSP server for $EDITOR, but to get it I had to accept a couple syntax compromises enabled via 'use v7', I'd accept that.
I believe it was one of your initial replies that clarified that for me... the question of the justification/value-proposition. I believe the justification given is: this will help us appeal to new users. I'm not sure that the proposed syntax adjustments will accomplish that. After all, Raku polished several of Perl's rough edges. Where are its new users?
The conversation I'm really not looking forward to is:
Me: "Oh, and we're going to have to make a few changes to the Perl scripts, and re-test them sometime this year." Boss: "If we have to do that, let's just get $new_hire to re-write them in $flavor_of_the_month."
That is not as unreasonable as it sounds — small changes here, small changes there, repeated enough, could add up to a complete rewrite. A reasonable manager could legitimately worry about a repeat of the PHP 5 fiasco.