Yup. By the way, MVI is really no different from Redux, it’s just a different name which I wish people would stop using because Intent is already used in Android with another meaning. I think “Unidirectional architecture” or “Flux variant” are better.

As for your analysis, note that Action in Redux is the same as Result in the referenced example. It’s just a data class containing the data to be used in the transformation and should be kept that way (no lambdas or other complex stuff). Your analysis of Processor is correct, it’s a middleware in the Redux world. Actually, it’ just redux-thunk.

Regarding the boilerplate-y class… indeed. In some scenarios it does cause more boilerplate. That specific implementation can be simplified. There’s no need to use Rx for a simple when:

when(action) {
   PopulateTaskAction -> Observable.whatever()
   …
}

So as you can see, it’s really not that complex. You can complicate things as much as you want and add generic middleware support like in Redux if you wish, but for a basic use case you really don’t need to.

The problem is more in the way things are explained. Same occurs with functional programming, literature tends to be unnecessarily academic. I can recommend this video where OO patterns are compared against FP patterns.