I'm always surprised to see bugs like this where an extremely easy to test part of the spec just seemingly isn't tested and ends up as a bug that never gets fixed until many years later.
The way I've seen it implemented at a small company I worked at before was to explicitly endorse the "20% time" idea that Google made famous, where you may choose your own priorities for a fraction of your working time regardless of the bug tracker priority order. Even if in practice you don't actually have that spare time allocated in your schedule, it does give you some cover to tell your manager why you are prioritizing little UI papercuts over product features this week.
Well, could be many reasons, "priorities" is usually the reason I see as the top reason for things like that to not be fixed immediately, rather than "we looked into it and it was hard". Second most popular reason is "workaround exists", and then after that probably something like "looks easy but isn't".
I think the solution would be to stop consider "easy-but-isn't" as easy bugs, even if they might appear so. So the "easy bugs" team would have their worklog, and if they discover one of those bugs weren't actually easy and would need large changes, reject it and push it somewhere else, and start working on something that is actually easy instead.
Not really. It's hard to see the difference from the outside without actually digging into it first, but in my experience while there's plenty of "easy" bugs that aren't actually easy, there's also plenty of easy bugs that are actually easy and that apparently everyone else assumed they're not, or else they would have been fixed already :P
This is a perfect expression of something I like to call Chesterton's Inertia. It's exactly the same as Chesterton's Fence.
What happens is that there is a mess on the floor, and somebody walks around it, maybe just because they were in a hurry, or maybe they didn't even see it. Somebody else walks in, maybe doesn't even notice the mess, just notices the faint trail that the last person left, and follows it. The next person walks in, sees a mess, and sees a trod path around the mess, and follows the path.
Years later, the path has been paved, has signage posted that doesn't refer to the mess, and has walls blocking the mess from sight. The mess has fused with the ground it used to just sit on, and is partially being used to support the wall. Every once in a while, someone asks why there's a weird bend in the path that makes no sense, and a old hand who's been around since the beginning tells him that the bend is a fence, and not for you to understand.
Whether or not you fix a bug weighs on the scale against the cost of all of the above things, the cost of time, the cost of these people's attention, and the opportunity cost of them doing something else. And these costs tend to not scale with the size of the pull request. They're fixed costs that have to be paid no matter how small an issue is.
I work at a BigCo, and occasionally get comments from developer friends about "Hey, why doesn't BigCo fix this obvious bug I reported! It's simple! Why are you guys so incompetent??" I look at the bug internally, and it's either 1. got a huge internal comment chain showing it's not as simple as an outsider would think, or 2. it's indeed trivial, but the effort to fix it does not outweigh the costs I outlined above.
But in general, I do believe that teams should be split on the priority issue in some way. If all you are doing is chasing the highest priority stuff, you're going to miss important things because priority isn't an exact science either.