A lot of this frustration comes from the concept of event binding. I simply don't believe in "global event" types. Meaning, I don't believe an event type has implicit meaning without a context. In the same way that a "submit" event type has no meaning unless it is bound to a specific Form object (in a standard HTML page), I don't see how any published event type can be useful unless the subscriber knows specifically which entity announced the event in the first place.
It is for this reason that I am beginning to believe that all events should be bound at the entity level. When I learn about things like Signals (one Object per event type), something about the enforced structure feels very satisfying. Binding event listeners at the entity level, however, does mean that two independent components need to be linked using either direct references or some kind of third part "conscious" entity.
In either case, you are left with a situation where coupling exists. Either the two modules know about each other and changes in one might precipitate changes in the other; or, a third entity needs to facilitate decoupled communication in which changes in either module may precipitate changes in the facilitator.
In both of these cases, you need to have objects that are aware of each other's functionality. And, once you're in that situation, it seems that you can more easily rely on direct method invocation for certain forms of communication. Rather than having to worry about keeping everything completely decoupled, you can leverage an informed, 3rd part entity to translate events on one object into direct API method calls on another object.
This is all a bit of stream-of-consciousness, so take it with a grain of salt. But, this line of thinking does stem from an ongoing frustration with event binding in modular applications; while I thoroughly like the philosophy, I am having serious mental blocks when it comes to practicality.
The battle for understanding continues!