Yes, I somewhat agree that it makes sense to have to types of event flows, buffered and conflated.

Buffered for events that should not be missed, ever. (For example, snackbars, but it could include other things like sending a broadcast, building a notification, etc)

Conflated for events like navigation where it is problematic for the observer to receive two (or more) back to back events of this type. Thus only the most recently sent event of this type will be received. However, I'm not entirely sold on it being a full solution to helping navigation events.

I dislike making it the emitter’s responsibility to ensure the observer doesn’t have race conditions. It’s conceivable that a sufficient enough delay in processing a navigation event could result in the observer seeing a second event before the first is fully handled, even with the conflated channel.

I see using a conflated channel as a way to mitigate this issue. But I don’t think it fully solves it. Given how "important" events are I'm personally hesitant to go this route.

Consider the following example: https://gist.github.com/fergusonm/ca387b98cd17eba3073df24529c46a85

The above example crashes. The delay is enough for the second event to be sent and picked up by the observer.