Introducing implementation-defined behaviour would undermine the advantages of Safe Rust. If I understand the goals of the Safe Rust project correctly, it aims

Introducing implementation-defined behaviour would undermine the advantages of Safe Rust. If I understand the goals of the Safe Rust project correctly, it aims to be a truly safe language, like Java or JavaScript. This means it must have no undefined behaviour, and beyond that, it should be as close to 'totally defined' as possible, without leaving program behaviour up to the particular platform, which would open the door to subtle bugs. (Concurrency is an exception here, as it really can't be made to be deterministic. Floating point might be another.) An obvious example: does this code result in a divide-by-zero? (I'll use C syntax.) int myInt = INT_MAX; ++myInt; int myOtherInt = 1000 / myInt; If signed overflow is permitted to result in myInt holding zero, then we have a divide-by-zero. Not the kind of thing that should be left up to the particular platform. The behaviour of your Java code does not change when you move it from a 32-bit x86 machine to a 64-bit ARM machine. That's part of the appeal of Java. The same should be true of Safe Rust. To put that another way: Safe Rust is remarkable because of its ambition: to be a truly safe language, while also having excellent real-world performance. It seems to be succeeding in doing both, without trading off on performance (Java, Go, C#) or safety (C++, and even Ada). If it starts compromising on either dimension, it becomes 'just another language'.