I think the proposal is specifically to bless a set of crates (that may include those developed by Rust teams, but probably also others such as regex).

Being in std implies some kind of quality standard, but it also implies no backwards incompatible changes. A set of libraries blessed by a trusted group could give you the quality standard without constraining backwards compatibility.

Regex is one of those crates.

No, they don’t. If the Rust team maintains a crate officially and they will always do so (for reasonable values of "always"), then it is part of the standard library. Otherwise, it isn’t.

It is as simple as that. When serious, important projects depend on a standard library is because they want those guarantees. Having some members of Rust work on some crates does not give anyone those guarantees.

Which is why all those crates must be in std, or declare that the standard library is a set of crates (including core, std and others).

I don’t see how that follows. Rust could easily have a (small) standard library that is guaranteed to be present everywhere and any of a number of optional libraries that are maintained by the same team that builds the compiler and the standard library.

That’s what java spent years on getting (https://www.oracle.com/corporate/features/understanding-java...), and I think that’s the way to go for any language. It prevents the standard library from bloating, yet provides quality libraries that can be trusted. It also allows some implementations to be standard without providing all the bells and whistles. That can be useful on small platforms, and allows for ‘heavier’ optional libraries (for example a SVG renderer, PDF parser, etc)

... I don’t see how that possibly follows. Not everything the project does is the standard library. The compiler, rustup, all kinds of tools.