[F.Rq.] A way for ext. tools to have child Lua scripts

Currently, I believe ext. tools are able to use reflection hacks to load Lua scripts from disk, modify their global state, and stop them (I have not tried any of this). Now imagine an ext. tool wanted to add to the Lua API surface—while possible, it wouldn't be pleasant for the developers of the ext. tool nor the script.
There are multiple options for implementing a nicer system, but I think the best way would be for ext. tools to subclass LuaConsole or otherwise have a separate copy of the Lua sandbox controller, and to be given full control over the API surface exposed to scripts. That model is similar to the Lua<=>Lua model successfully used by ScriptHawk.
Implementing some form of Lua host control for ext. tools would allow ScriptHawk and similar projects to get the "best of both worlds", in terms of more space for optimisation in the hot path plus a low (as far as Lua allows) learning curve for contributors. On a selfish note, I have an idea for a botting competition that would also benefit from this feature.

Start by examining LuaConsole and the existing external-tool integration to understand how scripts are loaded, sandboxed, stopped, and exposed to APIs. Define a supported host-control design that lets an external tool provide its own Lua API surface and lifecycle, then verify it with a representative ScriptHawk-style use case.