Я бы рекомендовал сейчас писать приложения вот так:

И потом просто убрать фрагменты

Абсолютно согласен про то, что это дело вкуса. Я в одном проекте просто захотел втащить Jetpack Navigation попробовать, столкнулся с отсутствием поддержки мультистека нормальной из коробки и с рядом других проблем, но в итоге решил все их и сделал так что использование навигации не вызывало боли и решало задачи проекта по навигации.

Спасибо за ссылку)

@terrakok Возможно сделать в рамках библиотеки Cicerone методы класса Router non-final? Было бы очень удобно не только расширять класс Router, но и переопределять его методы. Кейс, когда это было бы удобно: переопределить метод navigateTo(screen: Screen, clearContainer: Boolean = true) с передачей в clearContainer значения false по умолчанию

а почему не экстеншн?

Хочу оставить нейминг navigateTo и скрыть дефолтную реализацию типа навигации под роутер

День добрый, а как в модо использовать также как и в чичероне флоу фрагменты? Или они там уже не нужны для сингл активити

это есть в мастере, но я еще не успел опубликовать в мавен.
все работает из коробки
запустите семпл из модо

Выполняю подряд 2 команды newRootScreen. Первая команда выполняется в onCreate у Activity, вторая команда выполняется в onResume у фрагмента внутри этого Activity. Внутри Activity есть контейнер, в котором располагаются фрагменты. У всех фрагментов и у этого Activity общий router. При выполнении 2-х команд newRootScreen выскакивает FragmentManager is already executing transactions. Как можно исправить эту ситуацию, кроме использования post при вызове newRootScreen?

Бывают кейсы, когда нужно выполнить навигацию вне Main потока (например, когда нужно открыть LoginActivity при определенном ответе из Interceptor). В таком случае было бы удобно, если бы все команды переключались бы на Main поток внутриCicerone (с фрагментами можно работать только из Main потока). На сколько это актуально было бы внести в либу? Вприцнипе реализуется 10-ю строчками кода +  ошибка FragmentManager is already executing transactions больше возникать не будет. При выполнении многих ранзакций почти одновременно эта ошибка все равно будет возникать без добавления сообщений в очередь сообщений

про многопоточку: это ответственность разработчика следить за синхронизацией и вызывать команды на роутере синхронно.
но выполнять команды на фрагментменеджере не напрямую, а через отправку сообщений - норм идея. будет круто получить PR в реализацию навигатора

(там строк пять должно быть в навигаторе, при получении нового батча команд оборачивать это в пост)

Будет 👌

Если просто обернуть код внутри applyCommands у AppNavigator в post {}, то расширить applyCommands  будет сложнее. Сначала будет выполняться код после post {}, а потом код внутри post {}. Тут вижу 3 варианта развития:
1) Добавить асинхронные колбеки beforeApplyCommands и afterApplyCommands. Выглядит красиво, но тогда ломается обратная совместимость, так как старый код, расширяющий applyCommands будет работать некорректно.
2) Реализовать внутри AppNavigator метод applyCommandsAsync, который будет добавлен в отдельный интерфейс AsyncNavigator. Внутри applyCommandsAsync через post {} будет вызываться applyCommands. Тут добавляется много кода, чтобы решить такой простой кейс.
P.S.
3) А можно впринципе просто внутри BaseRouter обернуть код внутри executeCommands() в post{} :) Как думаешь, можно ли реализовать отправку через post{} внутри BaseRouter или Router

@terrakok дашь совет как лучше поступить?

Обновил сообшение (добавил третий пункт)

В 3-м пункте и правда 5 строк получится

Всё таки тот краш был из за вызова роутера не в мейн треде?

Нет, из-за другого.