MVU# must provide a standard way of nesting reusable components. A starting point could be the Elmish help page. However, as showed in this article, there are many patterns for implementing parent-child communication.

In theory, a RequestHandler should only be a proxy between the application bussiness logic (pure) and a single method of an extern library (impure). In that sense, a RequestHandler shouldn't have more than one service injected by constructor. Should MVU# validate that? There are any cases in wich a RequestHandler must depend on more than one service?

MVU# must allow issuing navigation from the Update function, but as this is dependant on the view engine, so we have to find a way to abstract it and make the platform speciffic implementation in each adapter.

Elmish allows sending messages from other sources than the UI (timers, websockets, etc) throgh subscriptions. MVU# must support that too.

I have added a special RequestHandler called AggregateRequestHandler for implementing reusable Handlers. In other words: a piece of logic involving many calls to Mediator.SendAsync that can be extracted as a single Request for simplifying testing of Update functions depending on it. The AggregateRequestHandler should have only one injected service: an IMediator instance. The current implementation of this is inelegant and not tested. We must check that.

This framework is based on Elmish and MediatR, so I gave core concepts the same names they have in those libraries. This would make easier for developers familiarized with them to learn how to use this. However, in some cases it could be missleading, as MVU# doesn't copy exactly the functionalities and conventions of Elmish and MediatR.
With that in mind, should we keep the original names?

EF Core is the standard ORM for .NET so MVU# must work well with it. We probably don't need to change anything to make it work, but as EF Core is imperative and relies in mutability, we must provide some guidelines on how to use it in MVU# using inmutable records as entities.