I'm not sure there is a solution, because I think the current RFC process structure is fundamentally adversarial and puts the wrong burdens on the wrong people. The structure also doesn't lend itself to making decisions about what not to add, like the OP correctly pointed out in my opinion.
The current process:
- Tends to focus on whatever proposal in some sphere is the newest one, redirecting all related discussion towards that proposal.
- Makes it important for those that see downsides, better alternatives, blockers and so on to get in early and make themselves known, as they need to get their downsides listed in the RFC, requiring them to convince the author and the wider community.
- Makes it important for the RFC author to defend their proposal against the incoming assertions of downsides, suboptimality and blockers.
- Has the totality of the discussion spread across multiple places, which makes it hard to follow, hard to summarize, hard to get an overview. Most of the spaces where you can find discussions again are unthreaded and thus tend towards chaos instead of organizing themselves organically into subtopics.
The points above make it, in my opinion, so that there is always an adversarial and stressful relation between the RFC authors and the community. This is a perfect biome for emotions to take over and hostilities to emerge. That doesn't even really take into account yet that I find the process has a hard time to deal with things that are fundamentally subjective.
I'm not sure how easy it is for the various team members to get an overview of any given problem's/discussion's current state, and how confident they can be that they aren't missing anything without asking someone they trust and who is keeping closer tabs. But I'm sure it's not a picnic for them either.
I have my own idea on how named arguments could work without adding a new "feature axis" to Rust, aimed at being minimal. But I don't think there's any place right now where it would be productive for me to actually propose or even just publish it.
What I'd love instead would be a system based on position papers. Where solutions are proposed, and can be proposed (and are encouraged to be proposed) in parallel. So instead of a list of alternatives that has to somehow appear at the end of an RFC document, we'd have parallel exploration and actually contrast the solutions. The leadership would then make big and small decisions once the dust has settled so to speak. Those decisions being for example hard requirements making some solutions not fit, accepting solutions, postponing things officially as a whole while waiting for some other things to shake out, or stating what features are considered out-of-scope.
The downsides are often not specific to proposals, but general in the problem space. In the case of named arguments, the "should existing argument names become part of the API surface" is a common point that keeps coming back. It seems like the "to which degree is the Rust project willing to require stability from APIs that previously didn't expect to provide it" would for example seem to me like a good candidate to discuss and have positions on in general. Things like this would decrease the design space, and provide a way for more accurate community expectations.
In summary, I'm not sure any guideline would really help here. No matter how many "Pre-"s are in front of the word "RFC", if it's a community wide discussion that's where the minds will meet. And I think the current process lacks the emergence of specifics where the project could say "that's a hard requirement to have/not have for the foreseeable future unless something unexpectedly changes somewhere else".