See, I don't think it will; rather, it will just waste time on deciding on what to not consider for now and so on. We also have mechanisms today that allow for a measure of negative space: closing RFCs, postponement, and the roadmap. The latter already states what the major priorities are, and other things are by definition not major priorities (there will always be small things that don't take a lot of time that we can work on...). I think this works well. It's better to positively state what we believe is important right now rather than stating what isn't.
At the time of writing, there are 124 open T-lang C-tracking-issues (I cannot speak for other teams... not my business...). I have reviewed all of these 124 issues several times. Many of them are small things, others are old crap we want to remove but cannot yet because e.g. servo depends on it. Others are waiting on architectural changes like Chalk or on making NLL the default. Some things were made very recently to make tracking more fine grained. Some things are really small issues that cannot and should not be compared with bigger things. Other things are done or close to completion.
This is all to say that using this list as a measure of things to do is a extremely blunt instrument that doesn't account for differences and the weight of various items in the list. Many things in this list are being actively and quickly worked on. Negative RFCs and whatnot will not help, it will just give me more work and take time away that I would like to devote to this list instead.
The nice thing about our current process is that it deals with priorities, backlog, and bandwidth organically. Language team meetings start with going through triage (nominated issues, PRs, bugs, etc.); we then proceed to RFCs... If we don't have time for RFCs, it will just wait until we have time. This happens a lot; most meetings we don't discuss new RFCs.