This is a good idea; I started working towards such a thing. The only thing to be careful of is that it's going to be vary hard to tell what's a good design until you start having some code that uses it. I intentionally stopped developing a gh-lua stdlib because I wanted to see how people were going to actually use the lua first. So maybe it makes sense to implement some more content first?
In particular, I think adding all the cities would be good but wouldn't ask much from the lua. On the other hand, implementing quests - even just city-defense or sewer-clearing - would be an educational experience, and would make it much easier to tell what a good lua interface would look like. I'd recommend writing a few such quests at first using arenascript, augmented by whatever lua hacks are necessary. Then once we can see what's needed, get into redesigning the lua interface.
On a more technical note, there are two basic ways of exposing Pascal objects to lua. The first, light_userdata, amounts to handing lua a pointer to the memory. Lua does no memory management, and the object has no associated tables, no type safety, or any of that lua-level stuff. The second way is to make the object into userdata, a full-fledged lua object, allocated from lua and garbage-collected when appropriate. Such an object does have things like type checking and whatnot. As it stands now, gears are represented using light_userdata. For each gear, a lua table is (supposed to be) constructed to supply additional attributes and functions. This is implemented by having a registry of all gears that maps from the pointer to the associated lua table. I can't point to any specific problems this causes - though it's why there are all those "double registration" messages - but it seems like a very brittle mechanism. Many things that you might naturally try to do with lua objects are going to cause confusion when using this mechanism. (As a concrete example, it's not totally clear to me what is the right way to duplicate a gear - you presumably need to trigger a Pascal-level copy of the gear object, followed by a duplication of the associated lua structure. You probably also need to do something about the next, sub, and inv pointers.)
All this is to say, don't invest too much time in designing the Right Way to manipulate GH from lua, because we don't really know what our requirements are going to be yet.
