The commit doesn't include a mechanism for marking the should_skip_on_back_forward_ui flag, but the normal way Chrome verifies "user's intention" is waiting for a gesture/click in the page.

So if you're doing front-end routing in response to a user clicking on a link or button in your UI, or swiping the page or what have you, that will allow you to pushState and then intercept the back button, as you can today.

But if you attempt to pushState on load, that's not enough to establish intention; the back button will then skip your pushed states and leave the page.

Browsers will probably never be clever enough to tell which clicks had "the right kind" of intention. The arms race continues!

This is much better then the current solution where you have to long-clicking the back button and manually pick a safe entry.

"why would someone abuse this" shows an incredible naivete. Anything that can be abused will be abused.

There was a kind of "if we don't expand the web platform, native apps from walled-garden app stores will take over" discourse at the time, from all browser implementors — less so from Apple, which could hedge its bets with the App Store.