да я уж третий раз вижу этот скрин и согласен, что это по сути мои парамс-ы

это не тот же самый скрин

присмотритесь

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

приходите в пятницу голосом обсудить)

дело в том, что FragmentParams не подразумевают наличия таких параметров как Id и replacePreviousScreen

но их можно добавить)

если их туда добавить, то они уже не только к самому фрагменту будут относится, но и к способу его отображения

и к внутренностям реализации хранения стека

это уже смешение логики

в такой функции смущает то, что AppScreen теперь какой-то abstract fragment factory получился:
- создать фрагмент с возможным доступом к FragmentManager
- накидать кучу парметров с информацией об открытии этого самого фрагмента-экрана
- создать фрагмет с аргументами

AppScreen - только связывает ИД скрина и фрагмент с свойством его добавления в контейнер

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

а остальное - это как эту связку сделать

я понимаю вас, но AppScreen - это место где встречается кусок независимый от мира фрагментов с фрагмент менеджером

с одной стороны логика не должна ничего знать кроме ИД, а с другой стороны фрагмент менеджер должен сопоставить ИД и показать фрагмент (да еще и выбрать add/replace)

и получится AppScreen :))

если туда добавить ИД и возможность явно создать фрагмент

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

ах, да, имхо!

да, это отдельная история)
более того, это одна из причин появления Модо.

"она должна просто сказать родителю, что произошло какое-то событие" - это не в идельном мире, а просто в другом подходе