One of the original reasons for message passing is that multiple reducers can respond to the same action. There have been many libraries since the beginning that try to shrink that relationship (ex reducks), but I never understood it, my code is replete with multiple responders.
One example is fetching data, often it is more effecient to request data in a certain way, but the app needs it represented differently, multiple reducers can respond to the same payload and take what they need.
Another example is url updates, I use state-driven-routing and when a url update happens many reducers need to respond to get the pieces of state they are concerned about.
Another example is a login status change, many reducers may need to update themselves if a user logs in our logs out.
It's the difference between having tons of highly specific 1:1 actions getting called from the action creator with their relationship to the root action obfuscated vs. having 1 action that many respond to with their relationship to that action clearly denoted.
To take it a bit further, it reminds me of refactoring vs adding another "if" statement - the former requires comprehensive understanding of the holistic purpose of the system with the dependent relationships properly defined (anti-fragile), whereas the latter is a temporary bandaid that can be implemented with less thought (and the sideeffects that come with it).
There wouldn't be more than a single source of a given truth, the multiple responders pull different truths relevant to them, the combination of which making the complete app state.
Middleware. A UI events logger for example. Or finishing a network request may need to close some part of tge Ui and also trigger a reload somewhere else.
