It is, though. That's why it's not infrequent that we end up unaccepting even features that had approved RFCs and were implemented -- https://github.com/rust-lang/rust/issues/44524#issuecomment-988260463 is one example.
I think it's appropriate that on IRLO there's a bit of a bias for action. There needs to be a place to explore what things might look like, and I'm much rather that be here than in the RFCs repo. When that goes well, it can even convince someone that something they like isn't worth doing.
It's certainly true that there's long-standing concerns about increasing complexity. Some I could find in a quick search include
- Don't keep complicating the syntax (soft post, maybe off topic, maybe irrelevant)
- Fortifying the process against feature bloat
- Raising the bar for introducing new syntax
(Actually, those are all 2018, so maybe things have settled a bit since that edition?)
But as far as I know this is a constant tension in all languages. Complexity essentially never decreases in any language with enough of a stability guarantee that people are willing to use it extensively.
I would certainly like to see something like rustfmt's https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/principles.md for the language, though -- the way we expect various things to behave that are generally just not going to change. I've occasionally been attempting to reverse-engineer some of those, like when it makes sense for something to use braces vs parens (other than just K&R precedent).
Hmm, https://github.com/rust-lang/rfcs/blob/master/lang_changes.md is pretty terse right now. I wonder what people are finding before opening things?
At the same time, I think that there isn't really that much noise about the really big things like whitespace-syntax. Those end relatively quickly, the the documentation would probably mostly mean a link to include. (I don't know that documenting "no, we're not doing that" would keep certain things from being opened, because I don't know any single programming language that would actually entertain switching from braces to whitespace or vice versa. Either they have always supported both, or they're going to stick with their choice.)
Some of the ones that stick out to me as persistently noisy are the ones like "what exactly should matching mean?" or "how exactly should we be doing around error handling?", where I think things aren't really settled yet, so even though it's often painful to make progress on them, I don't think there's any "core design decisions" that are controlling there just yet.
Maybe named arguments are in that list too -- after all, there's Wishlist: functions with keyword args, optional args, and/or variable-arity argument (varargs) lists · Issue #323 · rust-lang/rfcs · GitHub still open from 2014 expressing explicit interest in something in that area.