I saw what you posted in the news section and I think what you posted might actually be a better idea if you go ahead with this whole shindig - users can provide a function to be invoked on entities, and the invoker decides where to invoke it (what thread/map - higher order functions). As for having one thread per map, this makes sense, as entities on different maps shouldn't be able to talk to each other anyway.
You're right in that the system shouldn't be fool proof and account for every eventuality. As for map messaging passing, if you do that, again, it should be transparent to the user. I don't think there is a reason to pass messages between maps if you keep a context object and each Lua object knows which map it belongs to.
You should only create states once per map initialization. And if you do A = 5 and then later on do print(A), if it's not in the same scope, then you have leaked state. You should not be able to guarantee A is equal to 5 outside of the current scope, IMO. This is a problem with global variables/leaking state in general, and I don't think it's something you should plan to try and work around - instead you should try and encourage users to program correctly. Encapsulating state inside of a table state context object that is passed around and unique to each script would be one way of handling this.
Better still, you could create a state "system" in which callers can ask for a state context object from the Lua engine, and populate it. Any changes to that state object can be called from across the application but it would be managed by C++ itself allowing for you to worry about the threading in the C++ end. It's not perfect but it's a best of both worlds situation - you still get to have some global state for scripts, and you don't have to worry about happened-before relationships (btw, the A example you gave is a happened-before relationship)