Observer pattern and ChangeManager

In the book Design Patterns (gamma1994design) page 300, Chapter 5 the Author describes ChangeManager as a technique to handle state changes when the dependency is too complex, but the author does not discuss whether the Observer pattern is the correct pattern when the dependency becomes too complex. Earlier in the book they do mention under the section "Applicability" they write: "When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled."

My question is: At which point should you realize that this dependency is too complex for an observer pattern, i.e. when are you forcing the pattern?

I believe answering this question is key to understand why the observer pattern has been deprecated, why this article was written and why the Spring tutorial for Kotlin refers to this Stackoverflow post as explanation on benefits of coroutines.

Most of earlier post on this topic easily dismisses the pattern which has its origin fram SmallTalk based on examples where perhaps the observer pattern was not the right choice to begin with. There is also claims that Listeners as implemented in Java (keyReleased etc) is not actually the Observer pattern becauce its to specific. Does that mean that the issue with the Observable implementations in Java was that it was not specific enough, and that it is still acceptable to create custom implementation of this pattern?

Java also deprecated the pattern because of thread-safe issues, and serialization issues.