So... options for enums in Lua (using Weapons enum as an example)

1) As things are now: Independent integers set in global namespace: WeaponPhaser, WeaponBouncer, WeaponTriple, WeaponBurst, etc.  Values are modifiable, though there is no reason someone would want to modify them.  Not easily iterable.  Lowest overhead.
2) Basic table organization: All values could be put in a Weapons table, for better organization: Weapon.Phaser, Weapon.Bouncer, Weapon.Triple, Weapon.Burst, etc.  Table is modifiable, and all weapons can be iterated over with Lua's pairs command.
3) Advanced table organization: Values in a table as in option 2, but table is not modifiable (for better security).  Values are strongly typed, meaning C++ programs can verify that a particular enum is a Weapon enum and not a Module enum.  This comes at the cost of having to check the types at runtime (not compile time), so there is some small overhead involved.
4) Intermediate table organization: Values in a table as in option 2, but table is not modifiable.  Values are not typed, and there is no overhead associated with using them beyond the table lookup.  Values cannot be iterated over without modifying Lua itself.

=== Evaluation ===

Overhead/Performance: 1 < 2 < 4 < 3

Type security: Only option 3 provides any type checking capability

Ability to enumerate all Weapons: Only option 2 provides that ability natively in Lua, though we could provide a C++ function getAllWeapons() or somesuch that would return a list of enums

Security against accidental modification of enum values: 1 < 2 < 3 == 4

Organization of values in global namespace: 1 < 2 == 3 == 4

All are roughly equal in ease of implementation.