https://html.spec.whatwg.org/multipage/browsing-the-web.html#traverse-the-history 4.2.1 and 4.4.2 refer to updating history entries that are 'contiguous' same-origin.

However, it's possible to have two non-contiguous entries that share a document:

1. https://static-misc-2.glitch.me/history-adventure/
2. location.href = '#foo'
3. location.href = '#bar'
4. history.back()
5. location.replace('https://example.com')

This creates 3 history entries:

1. https://static-misc-2.glitch.me/history-adventure/
2. https://example.com
3. https://static-misc-2.glitch.me/history-adventure/#bar

…where 1 and 3 can share a document. In Firefox, you can pass from 1, to 2, to 3, and be given the same document you saw in step 1. In other browsers, you can pass between 1 & 3 (eg go(2)) without the document reloading.

However, in Firefox, if you start in 1, and set window.name, then go to 2, then 3, window.name is now an empty string. If you start in 1, then go straight to 3, window.name is not changed.

Since 1 and 2 are the same document, the change in window.name is observable by script. It seems weird for the browser to change this value during the lifetime of a document.

Proposal: It's decided if one history entry should share a window.name with another at entry creation time (basically, depending on whether the preceding history entry is same-origin), and this remains true throughout the existence of the history entry. It may be split from other entries in edge-cases like above, but it's consistent with how history entries can share documents.

Alternatively, window.name could be scoped per navigable per origin, so if you navigate from origin A, to B, to C, to A, the two origin A entries will share a window.name, kinda similar to how they share session storage, although session storage is shared with iframes, which wouldn't be the case here. This seems easier to understand, however it's a bigger change from what Safari and Firefox do today.