話を単純に戻して整理します
質問A）
皆さんは非同期処理が複雑になってきたらどのような対処を考えますか？
例1)　コンテキストが変わると無効になるセッションをほぼ全ての関数に渡して置いて逐一セッション切れを調べるようにする
例2)　キャンセルの値や手段を定義してそれを伝播させる（Cancellable Promise）
例3)　その合わせ技のようなもの（CancelToken）
その他)

質問B）
>>114の状態で>>97の問題に直面したとき、
要するにいままで繋がってきた流れの中で突然安全にリセットしたくなったときはどうすればいいのか
例1)　>>114で言ったように、ブラウザがほぼいつでも安全にタブを閉じれるように、
つながりの根本の方に枝を生やしたり切り落とせるポイントを用意しておく
例2)　チェーンにを触れるPromiseをメモリリークを起こさないよう必死に再実装して明示的に切り離すようにする
例3)　生Promise+awaitに頼らない新設計を考える
その他)

質問C)
イベントを使うと不特定多数の直接知らない待機状態の処理を動かせて便利だが、
非同期処理のためタイミングが問題になる場合はどのような工夫をすればいいか
つまり、一方的にイベントを発火するだけではなく、それを全員がきちんと受け取って把握し
必要なら一定の準備ができたというフィードバックを得られるようなイベントシステムをきちんと整備するべきか、
それとも質問Aに書いたようなセッションだったり、今の共有状態変数を準備して対処するか
皆さんはどちらで組まれてるコードがお好きか

また他の場合でも一般に、問題解決のために高度に抽象化仕切ったシステムを作り上げたものと
例えばグローバル変数を１つ使うなどしてでも比較的シンプルに乗り切ったもの
場合によってそれらのスタンスを使い分け混合した状態
皆さんはどのスタンスで組まれてるコードがお好きか