I'd like to thank everyone for the fun discussion. It has clarified my thoughts on what a more exciting alternate-timeline perl7 would be. For what it's worth, here are my thoughts. Please don't take them seriously--I'm just some guy having fun imagining things.

Modernizations worth breaking existing perl code. The proposed changes don't thrill me enough to make me want to break existing code. Examples of what I would break code for:

• A repl.. When you run perl without a file argument, instead of reading STDIN it gives you a repl, and not an iPython knockoff, but a perly repl where you can alter the command grammar from the inside and available for programs to provide repls over ports like Lisps do.
• Retiring XS. Bring a first class API into the interpreter that insulates extensions from changes that need to be made in the interpreter. There would obviously have to be a prolonged grace period
• Objects. The semi-announcement that they'll put Cor in the Core is a good thing (as long as Cor actually delivers on its promises). But--if we can pull it into the language, that opens up interesting possibilities. Like, what avenues open up if an object is its own type of thing with its own sigil? And what could be done by adding object-context next to scalar/list/void contexts? Perhaps object-context plays a role in opening the door to auto-boxing the other types, as was mentioned in this thread elsewhere. I don't even know if it makes sense, but if we're going to break existing code, I'd really prefer to make perl-to-the-power-of-perl (huzzah), rather than keep naughty programmers from using bareword filehandles (meh).
• Perl on the Web via a webassembly cross-compilation target.

Then, we could have a perl7 announcement that says "we're breaking stuff but look what you get for it!", instead of "we're breaking stuff to take things away from you."

Things NOT worth breaking existing code. When your language is 30+ years old, if it's not big-ticket items like above, my stance is you should basically never break existing code. Follow the c++ model, and make extensions ugly but compatible. Old versions don't have to run new code, but new versions HAVE to run old code. That means prototypes don't move to attributes... perhaps signatures are relegated to attributes. Maybe say and state need different names or special names that can't conflict with anything else unless you add the aliases via 'use v7'. You'd get used to it. If you do it this way, you don't need feature guards on things once they get past the experimental stage, and you don't find yourself in 2020 where no one uses your features.