Random ideas what the current implementation of Lua could be replaced with (including both different Lua approaches and non-lua stuff potentially).

Advantage over KopiLua is probably improved speed of EmuHawk API calls, and increased simplicity in the garbage collection department. This latter one caused us many bugs in KopiLua I believe even though they weren't necessarily crashy bugs. Could run overall at speed comparable to Lua, but will probably never run as fast as LuaJIT.

Not necessarily any faster than our existing Lua due to high overhead for EmuHawk API calls; moreover, our existing Lua is HEAVILY CUSTOMIZED to fix bugs that make Lua nearly impossible to correctly embed in .net. These would have to be redone totally for LuaJIT.

Lua interpreter is simple; the RUNTIME is not. You'd need a whole managed Lua to be the runtime; the transpiling would simply be an add-on for that. There's a chance the transpiling results could be so cryptic and insane that the Lua runtime isn't required but basically kind of rebuilt in a stripped down way and dealt with largely in-line in the emitted C#... The interpreter can be simple precisely because the runtime is not; if the runtime is simple, then the interpreter or transpiled code take up the slack. Reworking the EmuHawk bindings would not be simple. Could improve speed substantially by taking advantage of internal optimizations or .net build and JIT optimizations too. May even approximate LuaJIT but not match it.

Allows custom tools to be built and plugged in. Seems to provide access to everything the tools have access too. May be expanded as needed unlike Lua, since this is just C#. Runs as fast as hawk does internally, no need to crasstalks. Each tool needs to be written in C# and compiled to a DLL.

Python

Give up and wait for NextHawk; use any interpreter you want through autogenerated bindings :)