Jay,
Yep. I thing the examples could be in the Sharded world different shards... or Different Applications, like Forums going in one direction while Blog in other.
The other practical issue is recovery. What if replication between nodes becomes badly broken ? Single direction replica allows reclone as last resort activity while bi-directional might be a lot harder to
recover as you need to decide where data is authoritative. It is easiest if it can be done per table/schema or something like it.
One myth you might want to dispell is what auto_increment_increment solves all the problems.... it helps inserts but does nothing for other potentially conflicting update.
If you look at the general "thery" of such disconnected operationsyou may think about "eventually consistent" model - after applying all events the data should be same on all nodes... which often would require what events from both direction streams can be applied in any order between them with end result being the same. Working on different data as stated above is a simple subset of such requirement.
If you can't get such property when you get into conflict detection and resolution piece which gets pretty tricky as application itself can't detect the conflict because replication is asynchronous and you need detection and also resolution to happen
at different level. This is the theory of it but there is not much support for it in conventional MySQL (there is some in cluster)