「ところで，世界の有限性が明らかになるなかで生きるとは，つまり限界超過生存（オーバーシュート）の状態で人類が生きるとは，ある意味で，人類全体が巨大な終末医療のホスピスに入るということではないだろうか？」と故加藤典洋が書いたのは今から7年前の2013年だ．これに全面的に同意するものではないが，2020年現在の世界をかなり正確に予見するものであったことは間違いない．限界超過生存（オーバーシュート）つまり，「生き過ぎてしまった」というのは個人的にも当てはまるところだが，「終末期をどう生きるか」ないし「老化とはそもそもなんであるのか」ということは問われなくてはならない．
ある存在が個体であるということは有限であるということであり，有限であるということは空間的にも時間的にも有限であることを意味するとすれば，個体である人間がいつか死に直面することは不可避である．生きていることには悲しみもあるが楽しみもある．いつか人はその楽しみを失うことになるのではあるが，そのプロセスを可能な限り苦痛の少ないものにすることが「老化」の本質であり，目標なのではないか？つまり，解体プロセスをできるだけ穏やかに進行させることが創造者の本意だったのではないか？そこには相当の創意・工夫も感じられるが，創造者の力を持ってしてもそれをパーフェクトなものにすることはできなかった．つまり，組み立てることは簡単でもそれを秩序正しく分解することはとても難しい．いま，我々が直面しているのはその問題である．
たとえば，ここに家と家を結ぶ入り組んだ街路を持つ一つの城塞都市があったとする．あるときこの街の市長が街の建て替えを思い付き，全住民に移転を命じた．移転して空家になった家屋は取り壊され，その家に接続する路はすべて封鎖される．ただし，この都市の路はすべて一方通行であるため，路の入口側で「この先行き止まり」の看板を立てなくてはならない※．しかし，一部の路は生活に必須な経路となっているため，封鎖ではなく迂回のための繋ぎ替えが必要になる場合もある．ある家から発する一方通行路の出口にある家を知ることはできるが，その家に達する一方通行路の入口の家を知ることはできない．移転が完了するまで残った住民すべてがこれまで通りの生活を維持できることがこの大規模工事の条件である．この工事を安全に施工するための指針を示せ．
※一方通行路の両端（入口と出口）を除き，この路に接する家はないものとする．また路同士は交叉しない（交差点は存在しない）．
「地図があればいいんじゃないの？」と言われるかもしれないが，この街そのものを1個の地図と考えれば，徒歩で実地調査するのと地図を読むのでは計算量理論（計算複雑性理論）的には何の違いもない．生活に必須な路にはさまざまな種類がありそれぞれに担当の係がいる．万一「この先行き止まり」の看板が出ていない行き止まり路が発見された場合にはその工事を担当した係のクビが飛ぶことになっているが，手抜きや情報漏れ，資源不足などいろいろな事情から完璧を期待するのは難しい．（構造物を解体するのはこれに比較するとはるかに簡単だ．一番外側/内側から1個づつコンポーネントを取り外してゆけばよい）我々がやろうとしているのはこのようなネットワークの秩序だった解体，ある種の制御された解体（controlled demolition）に他ならない．
▲MakeAbsoluteを実行後にTOPOLOGY::CheckAtypicalMarriageが実行されている この関数は結婚連結線の所属を決めるために常用世代番号を使って基本世代枠リストにアクセスしている
CheckAtypicalMarriageの計算では絶対座標系を使っているのでMakeAbsoluteより前に移動することはできない．物理世代番号を使うように書き改める必要がある．⇒実際，nbox->getGeneration() – MinGeneration + 1で物理世代番号に変換している．⇒対処した．
かなり厄介な話になってきた．⇒いや，以外に容易に片付いた．少なくとも描画までは進める．ただし，出口検査は水平スプリット検査を除いてすべて絶対座標変換の前に移動した．また，水平スプリット検査はなぜか相対座標系では誤動作してしまう．元々絶対座標系で動作するように作られているのかもしれない…
▲絶対座標変換フェーズでGEN2DEVを実行して系列枠不在が多発している 系列枠はgroupから取り出しているので世代操作とは無関係のはずだが…これは，MAKEABSOLUTEフェーズ以外では発生していない．おそらく，これまでも発生していたはずだが，世代番号の取り出しを実施していなかったため発覚しなかったものと思われる．不要ノードと考えられるので，どこかのタイミングでパージした方がよい．⇒結婚枠と結婚リンクは一体とみなされている．また人名リンクと人名枠(0)もつねに不離不即とされるため，パージすることはできない．
絶対座標変換から外してもよいのではないか？実際，計算しようがない．ただし，HIDE_EXPOSEという状態もある．HIDE_EXPOSEというのは初期状態ですべての描画要素が隠蔽リスト上にあるという状態を示すものと思われる．現行ではHIDE_EXPOSEはゼロという値を割り当てられているので，識別が難しい．⇒隠蔽リスト上のノードは絶対座標系変換から外すというのでよいと思う．
以下の関数はCLEARTABLEフェーズ以下（アモルファス状態）では無動作で抜けるようにした．これらは比較的規模の大きな関数で理論的には不可能ではないとしても，いま直ちに対処するのは難しい．
- NAMEBOX::RetrieveGhost
- MARGBOX::cancelBetweenTwo
PAIRLIST::cancelでデータカウント残が出てしまった．PAIRBOXのデストラクタで所属するPAIRLISTを割り出してdatacountを削減することは不可能ではないが，PAIRLIST自身で実施するデクリメントとかち合ってしまう可能性がある．⇒方法はいくつか考えられる．①削除中のノードにマークを付けておく，②削除中のノードの控えを取っておく．いずれにしても，PAIRBOX::DisposeからPAIRLIST::CleanSansyoでコールバックされるので，削除中であれば本体でデクリメント，そうでなければCleanSansyoでデクリメントする．⇒いや，単純につねにCleanSansyoでデクリメントでよいのではないだろうか？
PAIRLISTはremoveとRemoveという2つの削除手段を持っているのになぜあえてdeleteで直接削除しているのだろう？removeはRemoveを引数TRUEで呼び出しているだけだが，Removeはやや複雑だ．ノード対リストは端点共有ノード対接続チェーンというのを持っている．また，この関数ではdeleteする場合とnodl_floatでフロート状態にしたまま切断する場合がある．後者は別のノード対リストに繋ぎ替えするための過渡的な状態だ．cancelで直列リストのノードだけを（端点共有ノード対チェーンに接続するノード対を無視して）deleteしているのは，それによって枝分かれのリストも同時に削除されるためだろう．一度バックアップを取ってから修正に入ることにしよう．
PAIRLISTはCleanSansyoをLISTに引き渡し，LISTはそれをDATALISTにパスしているが，DATALISTでは何もしていない．PAIRLISTはリスト上の他のノードにもCleanSansyoを要請しているが，リストというのは本来接続関係なのでほとんど空動作になっているものと思われる．datacountはDATALISTで定義されているものなので，ここで直接管理すべきものではないだろうか？カウントダウンする専用のコールバック関数を作るというのが一番確実であるような気がするのだが…
ただし，それをやるとすると，DATALISTのすべての派生クラスでdatacount操作の修正が必要になる．PAIRLISTはDATALISTのremoveなどの関数を使っていないので※，実験的にまず，ここで試してみるのがよいのではないか？フローティングする場合は別としてdeleteの場合は必ず削除されたオブジェクトからdataCountDownの通知を待つようにすればよいのではないか？⇒実装した．まだ上がっていないが，結構おもしろくなってきた．※⇒使っている．