I like the education suggestion, and I like the idea of ‘seeing to’ the queue of things. However, I found myself pausing at a few places in this blog post, and I think it comes back to this bit:

A noble goal — however, during the last year or so, I increasingly felt that this goal is being used as an excuse to try and cater everyone. Rust is general-purpose, but it’s still fundamentally a systems programming language at heart. Unfortunately, some Rustaceans interpret “general-purpose” as “must be perfect for anyone and everyone.” I don’t think that is a good or even viable approach to language design.

In particular “systems programming language at heart”. Rust is a language capable of doing ‘systems’ programming [0], but it’s also capable of doing more than that (e.g. crater could be written in Java), as you note when you call it “general-purpose”.

But I’m not sure how you’re determining what Rust is “at heart”. I would understand something expressed from a particular perspective - e.g. with my OS hat on, I might make my biases clear and say “I personally am only interested in the features that lend themselves to OS implementation, and I think fixing the asm! macro is far more important than extra type system things”. This provides the context to see the shape of the language you’re envisaging when proposing a limitation of language scope, rather than needing to guess. E.g. I find pointers awful to use in FFI code - this typically falls under “systems programming”, but it means new syntax - I have no idea of your opinion because I don’t have much to go on.

Fortunately, there is a Rust team whose responsibility it is to think hard about the Rust language, both right now and in the future - they need to take in the different shapes of Rust that people envision, and try and synthesise them into a coherent whole. I may disagree with some decisions (which may regress maintanability/teachability/consistency for a ‘shape’ I care about in favor of something I oppose), but I do trust the team and their steering to improve Rust overall. I realise it’s hyperbole, but I don’t think anyone is even close to pursuing “perfect for anyone and everyone” and I’ve seen ‘negative scoping’ on RFCs in the past.

On the subject of language design the post goes on to say:

Stuffing the language with more and more features just to ensure that more people will like it is marketing or even compulsion for conformity, and not a professional way of solving a technical problem.

and you mention in your suggestions:

Thinking about the bigger context. Not sacrificing the long-term maintanability, teachability, and consistency of the language for short-term goals.

I feel like the first quote goes without saying, but the second quote suggests you think there’s something to improve on? I don’t have the impression that the language team takes these matters lightly so I’m wondering if there’s a concrete suggestion (otherwise it sounds like business as usual!). That’s not to say things can’t improve - for me, I wonder if being more explicit about language shapes (OS dev, beginner friendly, …) would help understand rationale behind RFCs. I’d have to think more about how that would work.

[0] there are a few definitions of systems programming, but let’s say it roughly means “you can build an OS, and you can manage your own memory”