From there you can get to autounboxing-style optimizations. (Remember that research into Self and Smalltalk and Strongtalk shows that 90% of all dynamic language programs are statically analyzable.)

I assume that this is more a nod to perl6/parrot than perl5.

I do wonder about the effectiveness of a strategy of looking at runtime optimisations for languages like Perl. It makes sense for Java and Javascript--at least for download&run applications--because you cannot know the platform before runtime. But unless it is seriously envisioned that there will be a browser plug-in, it doesn't make as much sense for Perl.

Perl 6 (Python, Ruby etc), would be better served by compile-to-native facility I think.

I assume that this is more a nod to perl6/parrot than perl5.

It's much more likely for the former than the latter. Nothing in the design of Perl 5 makes this impossible—most of the problem is that the internals of Perl 5 make it herculean.

Perl 6 (Python, Ruby etc), would be better served by compile-to-native facility I think.

You can only get so far with AOT compilation because you can't coalesce all variant types into a single possibility in most programs without evaluating them. That problem is worse in Perl 5 than in Perl 6, but it still holds true for any program where you have runtime manipulation of metaobjects (or byte code or parse trees or...) or dynamic loading. You can use a technique such as profile-driven optimization by running a typeful profiler against a comprehensive test suite, but even in that case you probably have to add guard conditions to your optimized code as a sop to uncertainty (if you trust your test suite that much).

(I know you know this, but perhaps other readers do not.) eval and dlopen and AUTOLOAD and gradual typing mean that you don't always know enough about what's going on in any given code unit to optimize it fully until you actually execute it.