In very partial defense of this idea:
> There is not just one definition of "safety", and we can achieve a variety of kinds of safety
I agree, but C++ and Rust both fail at what I could consider a major form of safety not too far below memory safety. It might be called “capability safety” or “effect safety”: a function call should not be able to have side effects or read data outside that explicitly permitted by the caller (or importer or program manifest or whatever). I would consider a form of “unsafe”-like escape hatch acceptable so long as using that escape hatch is itself treated as a capability.
Rust and C++ don’t do this at all, although I could imagine it being retrofitted into Rust or a similar language. Java sort of tried, and it was a near complete failure on many counts. Several experimental languages have this as an explicit goal.
Some container and VM systems attempt this sort of security. Sandstorm was a notable example.
I guess you want something like the IO monad in Haskell and similar languages. I'm not sure how that would or could slot in Rust. I guess all IO could return something like an IOResult (although, I guess Result could do that too that, but it's not "enforceable" in the same way it is in Haskell).
I like the idea in theory, but depending on how it's implemented at the language level, it could end up being a bit hit or miss.
https://github.com/austral/austral
Deno does something along these lines too. WASM does, too, if you squint hard at it.