It seems like there's a tension between making implementation details part of the API (so you can catch mistakes) and hiding detail (which improves reusability and makes changes easier).
For example, if every function is allowed to allocate memory whether it does or not, then changing the implementation of a function so that now it allocates memory is a simple, backward compatible change. If you have to declare that you allocate memory (for example, by adding a new argument, as in Zig), making the same change breaks compatibility, so now you have to change all the callers.
Depending on the circumstances, that might not be considered worth the trouble. It's a reason that Java's checked exceptions aren't popular. Often, reporting a new kind of error shouldn't be a compatibility break; they're all going to get caught and logged the same way anyway.
(An extreme case would be making performance guarantees part of the API, which, outside maybe real-time environments, nobody does. This means that a new version of a library could be much slower than before, maybe causing your servers to become overloaded, without any compiler warning. But performance depend so many factors that making guarantees is usually unfeasible.)
The proposed idea of having a compiler do certain context checks without declaring anything in the API means that there are invisible API constraints that are generated from the implementation. This is sort of like having type inference without the option of declaring a function's type explicitly.
For example, if every function is allowed to allocate memory whether it does or not, then changing the implementation of a function so that now it allocates memory is a simple, backward compatible change. If you have to declare that you allocate memory (for example, by adding a new argument, as in Zig), making the same change breaks compatibility, so now you have to change all the callers.
Depending on the circumstances, that might not be considered worth the trouble. It's a reason that Java's checked exceptions aren't popular. Often, reporting a new kind of error shouldn't be a compatibility break; they're all going to get caught and logged the same way anyway.
(An extreme case would be making performance guarantees part of the API, which, outside maybe real-time environments, nobody does. This means that a new version of a library could be much slower than before, maybe causing your servers to become overloaded, without any compiler warning. But performance depend so many factors that making guarantees is usually unfeasible.)
The proposed idea of having a compiler do certain context checks without declaring anything in the API means that there are invisible API constraints that are generated from the implementation. This is sort of like having type inference without the option of declaring a function's type explicitly.