I do think that "leave no room for a lower level language" is not a helpful slogan at this point. It made a lot of sense back when C and C++ were new and needed to be sold on their merits, but for me, when talking about Rust in 2020, it sounds redundant at best.
It's already uncontroversial that there is "no room" between Rust and assembly, at least at the level of core language design. In fact, from what I've seen it's significantly more controversial whether there's still "no room" between C/C++ and assembly (most bluntly: "C is not a low-level language"). It also seems pretty unhelpful as a guiding principle for evaluating feature requests; I don't think anyone is arguing for inline assembly on the basis that it's "lower level" than "outline" assembly.
More abstractly, but IMO even more importantly, I think a huge part of the value of Rust is showing us how much the "low-level" vs "high-level" dichotomy is not a fundamental law of programming language design, but a historical accident. We've all seen plenty of examples where using the "high-level" feature optimizes much better in practice, especially when composing several abstractions in a larger project. So I'd much rather dispense with all this talk of levels in our broadest value statements. All the posts in this thread disagreeing over what the slogan appears to mean at first glance seem to me to prove that the levels metaphor has simply become counterproductive.
Of course, the intent behind slogans like "leave no room for a lower-level language" is usually accurate and well-meant, even if I'd strongly prefer not to phrase it that way. For example, I think it is uncontroversial to say that coming to a community consensus on what, if any, form of inline assembly Rust should have is a higher priority than coming to a community consensus on what, if any, form of dependent typing Rust should have (and not just because const generics is already accepted). Similarly, I believe figuring out const generics, GATs, placement new, etc are significantly higher priorities than figuring out delegation, named/optional parameters, fields-in-traits, etc (incidentally, this is why I haven't been talking about delegation despite it being the closest thing I have to a "pet feature").
I don't currently have an alternative catchy slogan to encapsulate why I think that's the case. I'm also convinced by the arguments above that a priority ranking like "1. safety 2. performance" would be similarly unhelpful, inaccurate and misleading. The cases where they conflict tend to be far more complex design decisions than "N safety < 2N performance, therefore perf wins".
If I had to take a stab at defining what Rust is all about in slogan form, I'd probably go with something like "raising the bar for all aspects of systems programming." But for marketing purposes, I think the actual marketing slogans we've been using historically like "fearless concurrency" and "memory safety without garbage collection" and "fast, reliable, productive — pick three" are already very good, perhaps even close to optimal.
On the subject of proposals to opt-out of unsafe and other forms of "unsafe fear" (if we choose to call it that), everything I have to say is in this painfully thorough post:
and AFAIK nothing has happened since then to change any of the reasoning summarized and synthesized there. So I'd like to avoid us retracing that entire design space yet again. If @matthieum or anyone else has a genuinely new idea in this space that doesn't succumb to familiar objections, that would easily deserve a whole new thread.
Stepping all the way back to the original premise of this thread, my honest reaction to the goals articulated in the paper is that Rust already embraces all of them in a broad sense, albeit with very different wording and with many small details changed (e.g. the priority ranking might be helpful and accurate in a C++ context, but for Rust I think it'd be a distraction at best).
This may sound incorrect for "Backwards or forwards compatibility" as a non-goal, but they're clearly talking about a much more draconian sort of "compatibility", and loosening that in favor of enabling more "language evolution" would essentially be bringing C++ much closer to what we might call Rust's "stability without stagnation" policies.