Not in my monorepo.
I have compile time boundaries between modules and I cannot make them particularly entangled with each other.
Maybe the problem you have in mind, is more likely to happen in dynamically typed languages? Where there's no compiler who can say "No."
I now believe that monorepos can only work well when there is a mechanical tool for ensuring correctness and that refactorings can be done atomically across the whole tree. Infact, it might be necessary to _only_ commit the refactoring operation to the tree and the source itself. That the whole tree is a blockchain of tree edit operations.
Isn't a compiler such a tool? I use a statically typed language, and if I would try to do this:
> everything can reach everything else
then there'll be compilation errors.
This is especially true in monorepos. Code resuse has it's benefits, but left unchecked the dependency graph can turn into a huge highly-connected glob. Modules end up accidentally importing code they have no business importing because of sneaky transitive dependencies. The blast radius of even small simple changes becomes enormous, and testing/debugging becomes more and more complex.
A great way to keep this in check is to have apply code isolation in the test environment. When you checkout the entire repo for a build or test, its easy for these kinds of dependencies to grow unnoticed. But if you require build/test targets to explicitly declare what code they depend on (and only make that code present when running them), changes to the dependency structure must be explicitly acknowledged in code review. This is one of the core principles behind build tools like Bazel.