I think adhering to the Solid principles prevents those problems. Single-responsibility should prevent two things working on the same data, dependencies should only point to abstractions and if you feel that a class hierarchy is hard to change favor composition over inheritance.
I honestly don't see how SOLID avoids the problem I mentioned, but let me clarify this:
When I say dependency, I mean it in a general sense, i.e. if a stateful object A uses a stateful object B, e.g. by composition, then A depends on B. So the behaviour of A does not only depend on the state of A, but also on the state of B. It does not matter if A or B are defined as abstractions, because in the end all object instances are concrete. These dependencies will always form a directed graph in some way.
You are correct that the principle of single responsibility prevents two objects working on the same data. However, as I wrote earlier, this means that the dependency graph must be a perfect hierarchy, also known as an arborescence or out-tree. A perfect hierarchy does not allow shortcuts, so if A depends on B and B depends on C and A wants to know something about C, we always have to go through B, regardless of whether we are actually interested in B or not. This is what I mean when I say that data access is baked into the dependency graph, making it difficult to adapt OO programs to new requirements.
But the alternative is that more data needs to be exposed and then if you change that data all the functions that operate on it need to be changed. This is a well known problem. With OO you can change some of the data/state (and the resulting behaviour of the system) with just a local change. But if you want to change the functions then you are out of luck.
