First of all, thank you for the article.

I would add my couple of coins here if you don't mind. It's not about you're wrong somehow, just a bit more details under the hood.

1. Sharing of UI library. It means any sub-application ("projects") should share the same UI library and other 3rd party heavy resources somehow.

2. Sharing of global state.

3. Sharing of local states and actions/APIs (inter-module communications)

4. Dependency resolving. If Project A requests some data, or action, or UI from Project B - it somehow should be resolved, especially if B also needs C.

So, with Angular & Webpack's Module Federation most of these are already somehow mitigated, but if you want to build heterogeneous systems, where modules are built not upon one framework, or if you need manual control of flow, you need to take such things into account.

Moreover, Microfront introduces at least two separate level of intercommunications: internal, between parts of platform - like DI, lazy loading, mounting/unmounting of UI parts, and external. I name it as "userspace" - logical layer of communications between the "projects". And next step in any (ok, in the most) middle-scaled app is exactly communication between the projects we're carefully isolated on previous stage =)

By my humble practice I'd say - micro-frontend platform should be framework-agnostic, otherwise better approach is just using of framework's features, and sharing the APIs/states is the key.