I agree this one received more than its share of beating, so I was reluctant to bring it up. But now I’m glad I did, because after what you say here it now makes much more sense (even the somewhat visible displeasure of the team members whenever this one is brought up). Each „side“ operated under very different understanding.
I mean, I didn’t know about this policy. The motivation in the RFC is somewhat inadequate to warrant any feature, even a small one. If I read just that, it makes me sad why anyone would add to the language just because of that, so I have a tendency to express my dissatisfaction (which, I guess, went a bit viral in the community). But if it wrote „Make the grammar more flexible in regards to | in patterns and make it more consistent with other separators which are allowed even at places where not necessary, in part to make life of macros easier“, it would give completely different impression. If one of the first comments at the merge request said „Oh, we usually allow these little details even without RFC, according to our policy [link]“, that would also look different. But reading just the information available there, it gives the impression of very „Oh, why not“ feature.
There were several interesting revelations in this thread regarding the working of the teams that explain a lot, but are not AFAIK commonly known ‒ at least I didn’t know them and I try to follow what happens around the language ‒ I regularly look at this forum, I have the subreddit in my RFC reader, I hang out in several rust gitter channels…. Therefore, I have to ask: are these things documented somewhere? Is there a checklist what to look into when you’re evaluating RFC? The policies like the one you just described? Would it make sense to make them more visible, so people don’t react out of ignorance? Are the meetings recorded somewhere (I’ve found rust-lang/minutes, but these seem to end about a year ago), if one is interested in following the discussions? I don’t want to say you try to operate behind closed doors, but sometimes it needs a thread like this to understand what is actually happening.
The thumbs-down thing: I understand these are not an input to either pass or sink a proposal and I don’t even think of different output of the team as „overruling“ ‒ there’s nothing to overrule. But I think it is a valuable mood-meter that can indicate some general unhappiness about something. It probably should be an input to investigate into what the something might be. The discussion raised the number of them, but found an excuse for them. In the light of „this doesn’t really need a full RFC anyway“, it makes sense to dismiss them, but it still gives impression you don’t care what the community thinks and that it feels unhappy. I guess more investigation into dissatisfaction would happen on a „full blown RFC“, but again, it wasn’t clear there’s actual reason to consider the RFC not being „full“ in the eyes of casual reader. Small, yes, but that would still deserve it’s due process.
If I try to restate the motivation and the missing sections in the RFC (without changing any of the technical parts) so it better explains the reasons and hopefully makes a better impression even without knowing all this background information and send a PR, will it have to go through a full-blown process, wasting your times, or can it be counted like a small fix that doesn’t change anything and could be merged in some lightweight manner? To avoid further discontent of people who read it ‒ after all, RFCs don’t act only as decision process, but as kind of a documentation.