No, I really do get it. Searching for a previous bug is part of filing, and you're talking about bugs that were filed three or even four years ago - so back whe

No, I really do get it. Searching for a previous bug is part of filing, and you're talking about bugs that were filed three or even four years ago - so back when none of the current browsers were anything remotely like what they are today. As such, you (and others) should refile them going "these were marked wontfix 3~4 years ago but the spec and adoption has changed since then, please reconsider implementing this". I lost track of how many specs had to go through that. This is not "busywork for maintainers", that is how updating specs work. You WONTFIX a spec when it's too early, and then people can refile once the spec's been reworked, made usable, etc. If your project is the size of a browser, the number of issues you immediately close rivals or even eclipses the number of issues you actually work on - it's why you have weekly/daily triage sessions to go "what's now in our bin since last triage? dupe dupe wontfix dupe assign request-for-clarification wontfix, done let's get to work" I work for one of these companies, pretty sure I have at least a decent idea what I'm talking about. We WONTFIX specs that are too drafty, and then one or even more years later, you refile an implementation issue because the world has changed, and what was WONTFIX in the past, is now worth doing.