I think maybe we're splitting hairs here. The point is, the only way for something to be accessed outside of a module is through its boundary, so if something has gone wrong due to code outside, it must be to some code inside that has been exposed incorrectly. That means the fault lies inside the boundary.
That is just to say that if an API that purports to be safe turns out not to be safe, then that's a problem with the API. The statement is true but tautological. Thus, I don't see how it could actually help to narrow down the source of, say, a segfault in a real-world debugging scenario.
You could establish the same convention for C++. Let's say that any C++ module that exposes an unsafe API is at fault for doing so. Great, now we can localize the "blame" for any given segfault to the module containing the code that actually dereferences the invalid pointer. Of course, the bug is just as easy or hard to fix as it would have been without this semantic convention. Maybe it's an easy one line fix. Maybe modifying the module to have a safe API would require a total rewrite of the rest of the codebase.
Because the root cause is smaller than “anything anywhere”, and you can control that scope. Rust gives you tools to deal with this. It is true that if you don’t use those tools, they can’t help you.
You can’t make a convention in C++ in the same way, because the safety aspect is not part of the language. I mean, you can, but it won’t help you the same way Rust will.
A more reasonable statement would be something like "Rust makes it easier than C++ to write modules that wrap unsafe operations behind safe interfaces". That's true, but it's not true that module boundaries somehow inherently contain the effects of unsafe code. It's pretty clear that they can't do this, given that the code all ends up being linked into one executable. Thus, makomk's original comment seems entirely correct to me.
