The last time I looked at this answer, unfortunately, there was no answer.
You also need to remember that Lua can call libraries that can open files, malloc() , etc., and that any “reset” must deal with closing these files, freeing this memory, etc.
As an alternative to “resetting” the Lua state, you can simply arrange your code so that it does not need to reset; this explicitly requires that Lua code be written in a certain way. One way to do this is to insist that your Lua code is completely (or almost completely) contained within a function (s) and calls one or more functions for each action. Out-of-function code can (for example) return a Lua table consisting of links to invoke specific entry points; it could be called only once. Function (s), when called, will be cleared after itself, including clearing any hosted element libraries, open files, etc. Global variables should be avoided (if not constant). We successfully use this approach to ensure that Lua is analyzed only once, entry points are determined once, but relative small functions could be called very quickly with little overhead.
In the comments you suggested, you can lexically wrap Lua code in a function block. I think this is less flexible than the above approach, and has the following disadvantages:
You lose the ability to do "once init" (for example, for example, reading a fixed constant from disk)
You risk unpredictable things if the user inserts (for example) an inappropriate end ... function B() into his code
You limit yourself to one entry point per Lua state.
This means that the Lua code must be written differently (in fact, the Lua encoder submits the code in the required form). One possible way to do this is to use a fixed framework for this and require in code that will be called as libraries. I have not tried this approach.