My personal preference would be to just see the one startup entry. However I can’t even guess what this would do to the workings of Discourse or whether Discourse would have alternate ways of accomplishing the tasks for which it is currently using history pollution as a tool.
If I understand correctly, the newsreader approach downloads all the messages to the client, which is supported by a dedicated-purpose client app which maintains the user-specific administrative data locally in it’s own dedicated database. Discourse, on the other hand, wants to maintain it’s data at the server end and (mis?)uses a general-use browser feature to support some of the client-specific administrative functions. In the process it seriously impacts the general usability of the browser feature for it’s intended use. Is this a fair summary?
I realize that keeping data at the client end in a Discourse-specific file is a can of worms that makes cookies look like your fairy godmother, but perhaps more experienced people can come up with something that makes it all good. Can’t Discourse maintain this info for each user at the server end? Unlogged-in users for the duration of the session, others between sessions?
Maybe a good first step would be to provide the knob Sam mentioned and see what people have to say about the side effects when they turn it off.