Since it was suggested that I meddle, the problem stems from the fact that the History.js code that's being used on the user's page is firing a
statechange event when the page loads, which causes the current tab to be immediately reloaded from the server via AJAX.
As there's some latency in the request, you see the original page for a brief period of time, after which it's replaced by the re-requested content. Given that the original request was recorded as you having viewed the new content, the re-requested view returns the tab as if you had already viewed it, effectively "unhighlighting" the new entries you were viewing.
One potential issue here is that
#tabs a isn't bound to the event handler that would allow the tabs to be loaded asynchronously, so switching between tabs in the user profile requires an entire page reload. This may or may not be by design, but since the handler reloads the entire tab for the other cases anyway, it seems sensible that the whole profile would be handled this way as well.
The larger problem of course is that the History.js code is firing the
statechange event on load and the code doesn't account for this. I've used that plugin in the past, and I remember this being the case. However, the most recent version of the bundled code seems to actually not fire that event when the page first loads because of some changes in
isLastSavedState(). Swapping in the code used on Stack Exchange however did still result in the event being fired on load in the demo page.
I couldn't find the code that would compress to the version used currently in user.js, so I'm unsure how to account for the discrepancy, but either accounting for it in the code or updating the History.js code that seems to be included in user.js should most likely fix this issue outright. As a test, I swapped in the updated History.js code by intercepting the user.js request with Fiddler to return my modified copy, and doing so seemed to produce the expected (corrected) behaviour.