It seems like there is a core question to be answered here: do we want these roadmaps to be merely a "reflection" of what is happening, or are they something more? I think one of the things that we are currently lacking is a central place to discuss -- and come to consensus on -- what features and changes ought to be priorities. I was hoping that the roadmap could fill this role.
It seems like if the roadmap is merely a snapshot of what is happening, then it is more of a "dashboard", and it will not help us to drive to consensus here. (That said, dashboards and the like seem valuable regardless.) On the other hand, if we have a set time -- like every two cycles -- where we revisit the question, it will be a good opportunity for people to advocate for their favorite ideas, and also give everybody a clear time to consider those questions.
One of the reasons that I prefer having this discussion in a centralized forum, rather than spread out over the individual issues for each initiative, is that it lets us examine tradeoffs and search for interactions more easily. So for example we might all debate whether named parameters are a good choice -- it seems like something that could be done fairly orthogonally. Custom DSTs, on the other hand, are a core-language change, and hence probably have important interactions.
This seems to address @strega-nil's core concern:
It seems like there is nothing stopping anyone from doing large amounts of design right now. The very existence of RFC 1524 shows that. But we don't really have a good way to get feedback on the prioritization of an idea, or for feedback on whether the idea is considered to be "on the right track". I think that some of the other proposed changes -- especially pulling out the idea of motivation from other parts of an RFC -- will help a lot here, because it makes it easier to engage with RFCs before they have tons of detail and design behind them. But I can also imagine that being able to raise custom DSTs (say) during a roadmap discussion will be a good opportunity to make the case for why they are important, and see what the community has to say (as well as the lang team, of course).
I am sad that you see the teams as exclusionary. This is not the intention and I think definitely what @aturon's proposals are intending to address. I think the idea of study groups may be a fine thing, but I'm not sure it's necessary: if we succeed in moving all conversations to the open, and have a way to openly discuss priorities, then influencing Rust shouldn't require membership in anything -- study group or otherwise. It should just require showing up and making your case persuasively.
One thing about study groups that I do like was a point @brson made somewhere -- basically that there would be a nice way to get a broader picture of all the people involved in helping shape Rust's future (which I think extends far beyond the subteam members). It seems likely that @aturon's proposals around shepherding help here (they also offer an answer to the important question of what is the pipeline for becoming a subteam member). But I haven't fully dug into those proposals yet so I'll leave that for later.