My recollection is that this has never worked correctly (at least since I have been using the facility) unless one rigidly only views the oldest unreviewed edit in sequence directly from the watchlist. However, even doing that currently results in all entries being marked as viewed. It has definitely been the case that as soon as one starts clicking backwards or forwards in diff view then all edits are immediately marked as viewed wherever one is in the history.

All I can say to that is that it still works fine on my local test wiki, diffs in particularly work as I described.

I don't remember when the last time I specifically checked that it was working on enwiki, but I know it has worked as I described in the past.

I did just find a case that updates it incorrectly: viewing an old viewed revision for some reason marks everything as viewed.

In T320865#8318739, @Anomie wrote:

I did just find a case that updates it incorrectly: viewing an old viewed revision for some reason marks everything as viewed.

I'd like to add that I've found this problem to be somewhat inconsistent in a way I've not been able to nail down, but I get the impression that it is more likely to go wrong if the number of unviewed items in the watchlist is large and spread over a long time period.

Until recently my unviewed watchlist was up to a month long. I frequently got entries marked as viewed which hadn't been viewed. Also the opposite problem - failing to register that I had viewed an entry. This evening, my unviewed watchlist had only three entries all on the same page. I viewed them one at a time in strict reverse order making sure to go directly back to the watchlist without going anywhere else first. It behaved perfectly, removing only the entry that I had viewed.

Another connected characteristic I sometimes see on long watchlists, but may possibly be a different bug, concerns my setting to only list unviewed entries. On some sessions the entry is marked as viewed after I view it, but it fails to be removed from the watchlist (or at least not immediately)

I can confirm that opening any diff in the middle of unviewed revisions on my wiki marks all as viewed. Trying with old viewed revision does not have such a result. Looks even worse than T186506.

I think this is a duplicate of T250770. I spent quite some time looking at the code and debugging the stuff because I find this annoying too, and I observed basically the same behavior as in the other task.

The chain of calls is straightforward: WikiPage::doViewUpdates -> WatchlistManager::clearTitleUserNotifications -> WatchedItemStore::resetNotificationTimestamp.
The last method doesn't do the watchlist update itself but delegates it to a job and pushes it to the queue. In other words, the update is not immediate. Therefore, users sometimes experience (and complain) their watchlists do not reflect their activity when the job queue is busy (T218511).

To mitigate this inconsistency during the interim period between visiting the page/revision and updating the database, there is also a short-term cache that is written to immediately. However, there is a remark in the code (WatchedItemStore::getLatestNotificationTimestamp):

// If a reset job did not yet run, then the "seen" timestamp will be higher

In other words, when you visit an old revision/diff of a watched page, there will be a period of time when the page will appear as if you visited the newest revision, but in fact, when the update has run in the background, the markers in watchlist and history will correspond to the expected behavior.

The time the update takes to complete should be a few seconds or minutes, but if the short-term cache expires before it has run (one hour), you will also experience T218511. In other words, from "you have seen everything", it will magically change to "you have seen nothing" before things settle down.