Thanks for the interesting link. If I am reading it correctly, they are planning to do the thing that Mike Pall tells people not to do: target LuaJIT bytecode [1]. I'm very curious to see how that will work out.
Pall is thinking about how to create the most efficient implementation here and of course compiling to LuaJIT bytecode is not optimal there. However compiling to JVM bytecode is not optimal for any language except Java either, yet everyone and their dog does it.
Accepting sub-optimal performance in exchange for getting a JIT, garbage collector etc. for free seems like a good deal in many cases. Note that Pall estimates a development time of multiple years (!) for the optimal solution.
I wonder if they'll beat castl [0], which compiles JS to goto-enabled Lua (Lua 5.2+ and LuaJIT).
Targeting the bytecode directly will not buy much, it is very close to Lua itself, semantically. The LuaJIT parser and bytecode compiler are also wicked fast.
Furthermore, IIRC, the JIT works best with idiomatic Lua code, compiled to "kosher" bytecode by LuaJIT itself.
[1] http://www.reddit.com/r/programming/comments/badl2/luajit_2_...