multiple embedded interpreters?

[edwin@...]

OK, I got my proof-of-concept embedded lua interpreter for game
scripting to work (thanks Kevin Baca--I had read the documentation
but without your example I hadn't managed to put the bits together)
and I'm thinking about actual implementation issues.

The game design calls for each "team" of agents to be driven by
a file interpreted by an embedded script interpreter.  The total
number of "teams" is going to be from 3-8.  I was starting to fiddle
with supporting multiple team scripts from the same interpreter by 
loading multiple files and using various package/namespace methods
to enforce scope (so team 1 doesn't accidentally call team 2's "fire" 
method...) when it occured to me that maybe that was the wrong answer.

Lua's C API appears to be designed expressly to support multiple 
concurrent embedded interpreters.  Lua appears to be designed to
be small and not require a lot of resources.  

Is there any reason that I shouldn't just launch a new embedded lua
interpreter for each "team" that uses a lua-based AI, to avoid
all the possible scoping issues and such?  The total number of
concurrent lua interpreters is likely to be a handful at most, which 
doesn't seem like it would require too much memory, etc.  It looks
more attractive than the alternative of enforcing scope on multiple
chunks handled by the same interpreter. 

David