That's an excellent trick, allowing to attach several independant "metatables", each one with its own unique "index" which is a reference to a table, without depending on Lua's own metatable (which works as if we had attached it as the value of an hidden/nil key of the main table).
And it is definitely easier to access fields in these metatables and make sure they will also never collide with Lua's own use of some keys that are bound to Lua's own syntax (like "__index", "__newindex", "__add"...). In most cases metatables are not needed at all, except when one effectively desires to control Lua's own behavior.
But one "bad" thing is that these extra fields keyed by table will be enumerated by `pairs()` and the code may not be prepared to get keys that are neither strings nor numbers; note that these keys will still not be returned as part of sequences enumerated by `ipairs()` whose keys are only numbers (and only positive integers).
But one problem is when you want to return *structured* data from a database (including JSON data, or using custom datatypes that cannot be simply represented by a single number or string): this trick does not work and you still need the metatable instead to store the metadata for the dataset, or you can separate the dataset (in its own table) and your metadata (also in its own table) and pack them together in a parent table with predictable keys, like:
`{dataset={...}, metadata={query={...}, reply={status=200, msg='OK', timestamp=...}, session={uniqueid=..., commited=false, updatable=true, rollbackable=false, ...}}, ...}`
which also avoids any use of the Lua's metatable.
