First of all, why does the channel/flow not guarantee processing? I understand it does not guarantee that events were consumed, but it does guarantee sending them. I don't understand what's the problem with this approach, since if the UI consumer is not subscribed to a flow, it does not collect events. This means if the activity goes to the background, it will just process the events once it's resumed again, no problem, unless you're not using an unbuffered channel or dropping events too soon. And NOT processing the events at all should not be a problem, since they're just ui events, and the user won't see them anyways, they don't care about missed navigation event when they've closed the app. You don't put business logic into your composables that depends on events, do you, I hope, that would be a disaster otherwise.

Why would you model events as states, when that makes no sense logically? Introducing state variables for each event is just going to make the state cluttered with meaningless variables, hard to understand, and it will be easy to forget to update a variable. Besides, if the UI misses collection of a state, and it can, due to lifecycle, can be bad, since the ui will now have inconsistent state. I speak from experience, I've seen redux/mobius based architecture in a big project and they suffered because of the problems I mentioned above greatly. When talking about MVVM, a ui layer calling a function of the viewmodel is starting the processing of an event immediately, so I see no problem here (beside exceptions but that's another story). And applying this to MVI, sending an intent will result in calling of the reduce() function with almost 100% chance. What's the problem here? Seems to me like overengineering what's working alright. Take a look at various MVI implementations, we survive somehow. Without effects in states ¯\_(ツ)_/¯