Embedded Io Examination (Speed and Security)

I've been trolling around for a suitable scripting language for a game
project and I wanted to come back and check if some of my previous
concerns with Io are still things I should be worried about.

My particular use-case is partially similar to the UT architecture;
heavy amounts of code are going in to the scripting language and it
needs to be a language that I could describe as fun to use.  Io
definitely counts as fun (to me) and I appreciate how easily it can be
plied in to domain specific syntaxes, but my last experience left
these bitter tastes:

- The benchmarks appear to have disappeared; is Io still considered
faster than Python and closer to the speed of Lua?  Lua's speed
appears to be 'close enough' for most which means less would have to
be spun off to C++.  I'm already well familiar with the concept of
running profiles and spinning too-slow segments off to C but as I
categorically hate C++, the less I have to put there the better.

- Embedding docs have become more sparse; is it still relatively
simple (albiet tedious) to embed?  I have written a tool using Ragel
to scan over headers and make a tags file for methods/objects to be
exported, so I have quite a bit of tolerance for the needed
boilerplates.

- Sandbox safety.  I recall discussions here that in the past
(versions I used to use supported this) rendering Io safe to use by
potentially untrusted code was a matter of nilling out slots from the
Lobby before using the VM.  I also recall that this was changed at
some point, so I'm left having to ask: Realistically how would one put
a CPU/RAM throttle and remove access to dangerous methods?  I've seen
a sandbox header for the Io VM but it lacks many of the methods for a
normal one.

Coroutines are still in VM, and I haven't seen that Io requires a
global interpreter lock to run threads.  Both of these I quite like
(proper co-routine support pretty much puts a language on my green
list).

Currently I've been entertaining the use of Falcon; it doesn't provide
quite the same pliability (it /has/ support of prototypes as an
option, but prefers a more normal class tree.  I'm not yet sure if
Falcon prototypes can be cloned and check their parent chain for
fields.)  Some of the additional tools (like subscribing to and
waiting for message broadcasts) could be implemented in Io using raw
Io code, but it has a few elements which aren't quite as pluggable:

- Sandboxed VM.  It's relatively simple to tell the VM where it is
allowed to load extensions from, and the documentation points at ways
to restrict memory usage as well as suspend/resume the VM from calls.

- Platform-independent bytecode.  I like the bytecode setup so the
code isn't completely thrown out in the open, though it's not a
dealbreaker not to have this.  For the particular project it's going
to be very mod-friendly.

- Meta-compiler.  At any point in a script it's possible to escape to
an interpreter that runs during compilation; this allows you to do
things such as pre-calculate a table of formula results or emit
boilerplate by escaping to the meta-VM and printing code out on
stdout.  This gets compiled as normal code and is useful in some
circumstances.  I think this can be /partly/ done in Io, but is lazy
evaluation more than pre-compilation.

- Templating system.  ASP/PHP-like templating is supported by the
compiler and VM, albiet weirdly.  It's useful for cases like the
aforementioned header scanner since headers can be spit out, though
there are other uses such as serving web content that the templating
is more attractive perhaps.  This one could be bolted on to Io too I
suppose.