At the risk of proposing solution statements instead of problem statements…
There’s a bunch of really important ideas here that look ripe for delegation, distribution, and documentation. Hey, if @steveklabnik can use producer-consumer as an analogy, then I can call these the fork and join model of open source project management. 
How about a light SIG (special interest group) model to coalesce and promote Rust work in particular areas, tentatively named “Rust Accelerators” so we have a noun to work with? Groups with immediate potential plucked from the top of my head:
- Ruby
- Python
- JavaScript
- Scientific computing
- Bare metal (could call it “Embedded”, but there are some useful differences)
I haven’t included “server development” on this list because it’s far too broad a topic, but groups that focus on some aspect of server dev would be prime candidates, such as web dev.
Groups should be robust enough to changing or different needs within their domain, such as different approaches to creating bindings. Yes, it’d be nice if everyone used the same stuff, but diversity in evolution is also important. A good bit of Rust culture to impart.
These groups can also form the basis for future efforts such as the proposed SDK-style crate combos. Maintenance of meta crates could be given to the group leaders, etc.
What would a Rust Accelerator get?
- A patron from the Rust team, prior to blessing the group as official and/or its leaders as Rust team members (this is a bootstrapping step, helps distribute the Rust culture, etc.)
- A section or tag on the Rust Discourse instances
- A tag on the Rust bug tracker, to indicate Accelerator interest in a given issue (does bors have a “this user can add/remove this tag” function?)
- One page (only one!) to author and maintain in the Rust Book, to briefly introduce Rust in that domain and link to further info / docs
- A link on the web site or pages on the wiki that come with implied project endorsement
- Future stuff, such as administrative oversight of SDK-style crate aggregations, etc.
- Responsibility to report on group activities to the core team, assisted with helpful project infrastructure such as forum / bug tracker tag summaries, crate updates, and so on (some of this exists for TWIR, but we could automate a lot more, give dashboards to groups)
Why do it like this?
Delegate: We want the Rust core team to have as much time as possible for hacking, merging, writing, problem solving, etc., so let’s build a structure to allow new folk to make decisions and herd cats in their areas of interest. Giving someone responsibility is a great way to encourage them to rise to the occasion.
Distribute: In the usual sense that work shared is work halved (assuming perfect scal– never mind), but also: Groups become ambassadors and contact points for Rust in other communities of interest, grow new contributors, etc.
Document: In the technical sense and the social sense. Each group provides (at the very least introductory) technical documentation about their domain, but the existence and structure of the groups provide a map of the Rust community for newcomers. New pathways and answers to, “How do I get involved?”
What do you reckon?