Being able to specify a language outside an implementation is extremely useful to prevent hidden logical inconsistencies between different parts of the language, and makes the language more robust.

It also allows people to design new backends (looking at CUDA LLVM backends)by finding out the right abstraction to support performance. For example, implementing a C or C++ compatible CUDA backend required the C++ committee to make changes to the memory model / consistency guarantees of C++ atomics. If C or C++ had only depended on compiler implementation for it, then there would have just been different implementations with different guarantees with no consistencies between them, and no single way to even define why they were different.

Actually it was the other way around, CUDA was fixed to follow C++11 memory model.

There are a couple of CppCon talks on the subject.

Partially correct, even now, SG1 in C++ fixes a lot of things in C++ specification to allow for CUDA like approaches.

The reason it isn't circular is that if there is one implementation, even with good documentation, there will inevitably be lots of corner cases where the implementation does something, but it isn't written down anywhere. Independent implementations will discover many of these issues and they get clarified as part of the standards process.

So you can't really produce a high quality standard with only one implementation. You'll miss important details.

Rust is ,,A language empowering everyone to build reliable and efficient software.'' (from the home page)

Reliability at the extremes (where it may be even life or death situation) requires the developer knowing what the program (s)he is writing exactly expresses in Rust.

>requires the developer knowing what the program (s)he is writing exactly expresses in Rust.

That just need documentation. You don't need a standard for that.