この表が引くIDを配る名前空間。大きさの写しではなく名前空間そのものを持つ ——表を組むのは読み込みの途中で、名前空間はその後も伸びる。組んだ時点の大きさを持つと、 後から配られたIDが全部「表の外」に落ち、配られていない番号と見分けが付かなくなる。
ローカル配列の並び順そのままに並べたグローバルID列。
そのグローバルIDのローカル位置。この物が宣言していなければ missing。
この名前空間が配っていない番号は投げる。 名前を経由せずに作った数は、番号としてはそのまま 表を引けてしまう——壊れたIDと「宣言されていない」は呼び手にとって別の話で、黙って畳むと 引き方の間違いが「持っていない」として通る。
捕まるのは、どの名前も持たない番号だけ。 どのNameRegistryも0から振るので、別の世界が 配ったIDはたいていこちらの範囲にも収まり、番号だけでは見分けが付かない——そちらを止めているのは この検査ではなく、世界をまたいで物を渡さないこと。
特定の ObjectDef に閉じたローカル配列（PropertyDef[] / SlotDef[] など）と、 ゲーム全体で共有されるグローバルID空間とを対応付ける表。ObjectDef側は自分が実際に持つ ものだけを詰めた密なローカル配列を持ち（グローバルID直インデックスでは疎になるため）、 この表がその変換を担う。
型引数は引く側のグローバルIDの種類（GlobalId）。名前空間ごとに別の表なので、 プロパティの表へスロットのIDを渡すと型で止まる——通してしまうと、別の名前空間で同じ番号を 持つ何かのローカル位置が返り、持っていないはずのものが引ける。
in out（不変）を書く理由は NameLookup と同じ。この表が素のnumberの表へ広げられないことを見張るのはtests/architecture/globalId.test.tsで、in outはその一手段——今は不変の NameLookup を持っていることでも同じ不変性が出るので、この2語だけを外しても広がらない。