An integer history.index < history.length would be a big simplification for many history-based routers. Currently, many of these push/replace a "fake" first state when the app starts up only to record such an index.

There might be some privacy/security concerns, but I can't think of any negatives that are not already possible with history.length, history.back(), etc.

History state is used often for view-to-view routing in a single-page webapps. But it's also used for simpler features, such as closing popups and dialogs on back button. Doing this with the current history object is relatively hard. An approach I've run across a lot goes something like this:

1. When the app starts up, it calls history.replaceState({index: 0})
2. Then the app patches replaceState and pushState APIs to ensure that no one can accidentally overwrite this {index: X}.
3. The pushState method is patched to increment {index: index + 1} for each push operation.
4. The popstate event is is ambiguous: it could be due to link navigation or due to back/forward buttons. Thus, the app would keep {index: X} if available, or would assume a fragment navigation and would set {index: index + 1}.

This is all to be able to reconstruct index on any popstate operation. It's trivial then to do operations such as closing a popup/dialog and other history-based functions. This is best effort since a user can go back or forward several steps or iframe can push/pop state - which could easily get to the state that the app cannot track. In other words, {index: X} and the real current index could easily go out of sync.

Ultimately, what a system like this does - it emulates history.index property that I request here. Having this property would simplify things a lot and avoid patching the existing API.