Lua will never use it. The entire Parrot design goes against the design goals of the Lua authors -- the entire point of using Lua is less about the actual grammar/syntax and all about its very tiny, very fast, very easy to wrap, ANSI-C runtime.
If you're going to use a massive, powerful runtime, you might as well use a more capable syntax with it.
To be honest, I don't really see the point of mixing 20 different languages in a project anyway. It's enough of a nightmare when you have to mix 2, because finding "multi-lingual" developers these days is not easy (sadly). Most of the languages out there are really so close as to be redundant anyway. One of the things people love about Ruby, for example, is that it can pretty much entirely replace Perl.
On top of that, there's the issue of the totally different "API design" issues. A class/object in Perl might be called foo::bar, in Python it might be Foo.Bar, and in Ruby it might be Gluger. The methods might be named print, Print, put, write, display, etc. You end up having 50 implementations of the same damn thing to do things "the Python way" or "the Ruby way" or "the Perl way." This in turn destroys the possibility of actually mixing components written in the different languages because the HTTP component in Perl might produce and consume totally different objects than what the Python HTTP components are using.
Fixing that issue essentially requires that all these languages end up using a single shared standard library. Which in turn means _completely_ breaking compatibility with application written for the original runtimes.
Parrot as a low-level VM and runtime may be useful. It gives language implementors a set of pre-written and ready-to-use code to get a high performance runtime.
All this talk of mixing languages and sharing components and getting everyone to switch so rainbows can start shooting out of our butts is complete nonsense.