Meanwhile, for unsafe Rust, if you look at the Rust Reference Book, there is a single page that lists the possible situations for undefined behavior, with an added warning message:
“Warning: The following list is not exhaustive. There is no formal model of Rust's semantics for what is and is not allowed in unsafe code, so there may be more behavior considered unsafe. The following list is just what we know for sure is undefined behavior. Please read the Rustonomicon before writing unsafe code.”
Then when I look at the Rustonomicon, it says:
“Warning: This book is incomplete. Documenting everything and rewriting outdated parts take a while. See the issue tracker to check what's missing/outdated, and if there are any mistakes or ideas that haven't been reported, feel free to open a new issue there.”
So maybe that should be more prioritized if Rust really wants to get the reputation of a safe, stable language. (Safe Rust is good, but Unsafe is where the real devils are all hidden…)
But that's not what a language specification looks like. You will rarely turn to the ISO spec of C or C++ to learn something about the language unless you are trying to build a greenfield compiler. And while a lot of people want a second implementation of Rust for technical reasons, it's not as compelling as improving language documentation.
For example language documentation would look like: the `for x in y {}` syntax is called a "for" loop, which iterates over the expression `y` by calling the `next` method until it returns `None`. (this is bad, but you get the idea)
Language specification would be something like `for x in y { body }` is equivalent to
While that language might be useful for some users, it's primarily useful for compiler developers. And since there is only one compiler, a spec to that detail is not compelling.