Would it be a mischaracterization to say that the generated C is basically the source of the Lua interpreter + the statically compilable functions from the Pallene program?
From the point of view of Lua, Pallene works the same as C
If you want to produce a standalone executable, at the end of the day this executable will contain a copy of the Lua VM.
If you want to produce a library that can be "require"-ed from Lua, then you will produce a ".so" shared object file with just the Pallene functions in it.
Sand boxing is what really sets lua apart imo. Will custom allocators and dynamic code loading be supported? Will generated code implement the debug hook counters?
Pallene has been designed to seamlessly interoperate with Lua, not to replace it. So you can still use Lua when you need dynamic code loading or magic debug hooks.
Roughly speaking, from the point of view of Lua, Pallene is a system language like C. It is good for performance and calling C system libraries, but isn't particularly suited for dynamic code loading and sandboxing via interpreter hooks.
(Maybe trivially answerable by looking through the resources, sorry!) -- will Pallene still support `eval`-like behavior (like with Lua's `load` function(s))?
Don't worry, that is still a fine question. Pallene programs are still able to use Lua's "load" to eval dynamically-typed Lua code. But it is less likely that we would implement a function to load Pallene source code at run-time, for the same reasons why it isn't common to dynamically load C source code: Pallene takes longer to compile than Lua, and dynamically-loaded code usually isn't as performance-sentitive anyway.
Cool makes sense. Could actually still be awesome to have a Lua lib or some other runtime lib that can translate Pallene or some other type-annotated Lua format to plain Lua, just for typechecking and ability to use autocomplete etc.