Because the navigation API is scoped to same-origin same-frame history entries, we have a lot more freedom to allow manipulating it, compared to the joint session history represented by window.history. In particular, we could allow rearranging or removing history entries, or even updating their URLs. This is not a security issue, because it only changes the behavior of the app with respect to itself: e.g., if you delete the previous app history entry, that's basically the same as doing window.onload = () => history.back() on the previous page (which, again, is part of your origin).

There's a few cases people have cited where this might be useful:

• Invalidating logically-deleted history entries, either by deleting them or maybe by changing them to point to a 404 page or something: https://mobile.twitter.com/juandopazo/status/1356689596805836802 /cc @juandopazo

• Implementing stack-like navigation patterns: https://mobile.twitter.com/buildsghost/status/1356661396717543424 and https://mobile.twitter.com/maxlynch/status/1356672792226394113 /cc @mlynch. This would require some bookkeeping by the application or framework, and wouldn't be provided out of the box, but I believe the main primitive necessary is rearranging existing entries.

... probably there are more? Let's use this issue to track discussion.

Updating non-current entries' URLs and states, as opposed to deleting/rearranging them, is related to #7, but I think the lower-level concerns there are somewhat orthogonal to this thread. That is, whatever conclusion #7 comes to for updating the current URL and state, will probably port over to non-current entries, if we decide that such modifications would be useful.