This isn't a way of learning programming. It's a way of learning about the variation in the language design space.

That includes teaching the very point you're talking about. There is nothing in the mystery language approach that precludes having programs whose behavior is non-deterministic, and this would then show students to prepare for it. Indeed, it's an excellent kind of mystery language, by providing a sandboxed version that can focus precisely on non-determinism.

(I will not reveal whether such behavior exists in the current suite or not, to avoid giving away solutions.)

Yeah, debugging possible outcomes of undefined behavior in C/C++ is pretty much exactly a mystery language exercise.

With older compilers, the usual question is "Will `-2 >> 1` perform sign extension or not?" With modern compilers, the usual question is "What arbitrary constant can the compiler choose for `-2 >> 1` to maximize the number of provably dead code paths?"

Students who do these assignments spend a lot of time trying to distinguish between these mystery languages, and writing program after program that fails to tell them apart. The next day in class, they hear a simple explanation of how the mystery languages differ. I hope that one of the lessons they walk away with is just how difficult it is to poke at a black box, and a renewed appreciation for specs.

In this case perhaps it would make sense for students to learn Rust first. Much of what is undefined behaviour in C/C++ is a compiler error in Rust (perfect for this approach).

Students can then move on to C/C++ using a different approach, but already having learnt most of the concepts.