Speaking for myself only here, my experience in the gfx team
is that there are so many bugs that I cannot see the forest
through the trees.
A list with issues which are not blockers, but only barely so
and it would be really really good to have them fixed,
would certainly be a list I would look at and see if there is
anything on there I can pick up.
So I like the idea, I do propose to simply re-use most of
the blocker bug process for this, rather then inventing yet
another process. I guess this could even be integrated and
the way to get bugs on the list would be to propose them
as blockers as normal and then during the blocker meeting
when the vote says "no this is not a blocker" a second vote
is done to see if it is a critical bug.
As already mentioned, the CommonBugs page might actually fit most of the requirements
here. We often place important "almost blocker" bugs in there, issues which are
very inconvenient for many people, or critical issues for a specific narrow group of
people. If we know it's being used even by developers, we might try harder to include
important issues in there. It's not exactly the same idea that Matthew talked about,
but I think the overlap is definitely there. As a bonus, there's a quick summary of
the issue (which someone has to write, on the other hand, of course).