we also agree that the core hackers should focus on creating the right design, getting it working, making it work right, speeding it up -- in that order.

All I can say is: wrong call. As with pounds and pennies, take care of the microseconds and the seconds will take care of themselves.

You can't build a fast car if the tyres are restricted to 50 miles an hour, or the bearing to 1000rpm. Nor if you build the infrastructure using Victorian cast-iron (over) engineering.

Build a small, flexible, fast core and then see what nice-to-have features it will stand. There is no need for full MOP-style introspection -- no program needs it -- and the penalties it imposes are clear to see...

(I anticipate a lot more speed up again in 2014)

Based upon what?

Btw, if anyone reading this enjoys optimizing, it doesn't require C chops, but just Perl (mostly NQP, a small subset of P6).

This just doesn't ring true. If the C code that implements/underlies NQP is not efficient -- and especially if the design & architecture of the language runtime is such that it cannot be made efficient -- titivating the the code that runs atop it isn't going to yield the kind of gains that are required to bring it into the realms of real-world usability.

folk routinely manage to interpret my statements as being hyperbole and/or promises.

Your parenthetical -- carefully worded as it is -- sounds like a promise; or wild speculation; or dumb over enthusiasm.

Equally, claiming that +* is "a direct equivalent which retains the ST's generality and efficiency and substantially improves on its elegance." is hyperbole. Which does more harm than good.