Single page applications are now quite popular. Most single page apps use a different definition of "back" than browsers do, and there are times when the two treatments conflict.
Many, or most, use a local in-memory database to keep track of information without going to the server. They update that in-memory store as you make changes. For example you see a list of names: Mary, Robert, John. You click Robert and edit the name to "Rob", the name auto-saves. Then you click "back".
Because single-page apps control "back" when in the SPA, they do what most developers want. They return to a semantically correct page, showing Mary, Rob (just edited), John. Tons of apps do this. This is not what the browser does. The browser, if following the "back" specs, would show the out-of-date names of Mary, Robert, and John.
The theoretical conflict can also become practical. Think through this flow:
* Visit /names
* AJAX for GET /api/names
* See Mary, Robert, John
* Edit Robert's name to Bob, autosave
* AJAX for POST /api/name/4 with the new name Bob
* See Mary, Bob, John
* Click on a link, lets say to Mary's website URL
* Mary's website, new domain, loads.
* ...click back
The SPA loads up, and attempts to GET /api/names. However, the bfcache is at play since the native "back" behavior is running. So the stale API response, with the original names Mary, Robert, John is returned. The list of names on the screen is DIFFERENT than what the user saw after they edited.
Additionally most SPA apps presume AJAX calls return accurate data, however here the names are not the names currently in the database. They are only in the bfcache. You can imagine, with more complex data, ways this can cause complex and unforeseen failures.
This is a very poorly understood corner of JavaScript development even today.
[edit]: formatting