Once rust stabilizes, I think it needs an ISO standard like C and C++ have. I can't see automobile manufactures using rust without one. One reason C and C++ are still widely used is due to this. When we are writing code that is expected to run for decades, having a corporate/community backed language is not sufficient. We need global standards and versions that we can rely on decades latter.
What has the standard actually gotten C and C++? Basic features needed in every single code base like type punning on structures are standardly UB, while design-by-committee results in C++ feature hell.
It doesn't get any harder to write a function exhibiting a bug just because there's a standard saying the function shouldn't have bugs in it. No matter what, you are trusting a compiler vendor that the code it compiles and the functions it links against don't have bugs.
A standard is not a magic spell that creates better software through its incantation; it provides for multiple separate compiler vendors to be able to compile the same code the same way, which is a total fiction in C/C++, and not required for languages like Python or Lua. I view it as nothing more than the streetlight effect.
Prior to the C/C++ standardization process, every compiler implemented a different dialect of those languages, and there wasn’t a complete and accurate specification for them. Some very basic C code working with one compiler might not work on another.
I don’t think Rust or any other modern language needs to be standards-org standardized, but this is a different era; there is a single solid, well-documented, versioned reference implementation for Rust. That was never the case for C or C++.
Take the "defer" keyword in GNU C - it's valid in anything that has the GNU extensions but isn't standard C at all. And yet, some projects swear by it (it's not a bad feature, just nonstandard).
There's a lot of weirdness in C implementations even looking across LLVM, GNU, or even when picking which libc you want! Try porting any nontrivial project to work with musl-libc. You might find that it's not as easy as swapping in a target and building statically!
This is perhaps the whole rub with standardization - it's bought us as developers a lot, but it doesn't cover everything. The veil was kind of lifted for me when I started trying to use different Scheme implementations in a "standardized" way. I eventually gave up on that and just use whatever implementation I am most happy with (often CHICKEN, but that's a digression).
This gets more complicated with C++, which modern standards mostly requires C11, but then also doesn't support everything that C11 requires either. They're different languages but yeah, compilers are gonna disagree on some of the edges there.
[1] https://github.com/Rust-GCC/gccrs
[2] tangentially, Rust also avoids some UB discussion because the type system is a bit more complete in terms of its properties than C is, so they can resort to Option or Result when things get dicey in an API. Further, there's no official Rust ABI unlike C, so you don't have to worry about that either...