Конкретно в нашому випадку глобального стейту було мало і ми його шарили між shell та мікфрофронтами через контексти. В більшості наш стейт — це був кеш даних, отриманих з серверу і для його управління ми взяли React Query.
Тому глибоко у state management libraries не копали, але я з цікавістю почитав би про ваш досвід роботи з мікрофронтами зі складними стейтами)

Цілком робочий варіант, як на мене.
Особливо якщо не лякає дублікату коду, гірший UX при переходах між сторінкам та обмеження при шерингу спільних даних між сторінками через LS або query params.
Але не знаю чи дійсно буде простіше наконфігурувати кастомний білд під це, ніж взяти мікрофронти де це зроблено «з коробки» і отримати кращий UX, DX та більшу гнучкість (якщо раптом в майбутньому потрібно буде одночасно показати декілька додатків на екрані).

Так, але тоді у нас буде спільний процес деплою для обох фіч. Виходить, що навіть при мінорній зміні в календарику потрібно перезбирати весь проект і деплоїти його повністю. Розумію, що хеші зміняться тільки у файлів календарику і всі інші залишаться старими, тому фактично редеплой пройде тільки для потрібного функціоналу. Але тімці, що робить календарик треба знати про деплойний цикл інших команд і підлаштовуватись під нього. А з мікрофронтами у команди календарика буде свій незалежний деплоймент процес, який вони можуть проводити коли їм заманеться.

Мені здається, що корінь проблеми в непередбачуваності проекту на початку та зростанні його складності з часом. Тому вона точно буде існувати)