вот это мне меньше нравится - всегда закрывать экран. так как там может быть много кейсов:
- закрытие
- реплейс
- закрытие цепочки
- замена цепочек

те же фрагменты
сколько они уже существуют?
для них до сих пор не выкатили в релиз нормальную передачу результатов
гугл выкатывает фичу для разработчиков, а потом делает кучу костылей
касательно фрагментов это Navigation, FragmentFactory, Fragment Result API
и самое смешное, что даже костыли с трещинами и не без проблем

Можно написать свои фрагменты, как это сделали в telegram

я прошу еще раз

кстати да
непонятно закрывать только один последний экран или все цепочку, поэтому остается только один вариант -> оставить на откуп разработчикам

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

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

при закрытии цепочки может закрыться и слушатель, поэтому так или иначе там за все отвечает разработчик

Что думаете по поводу того, чтобы сделать это отдельным подключаемым модулем? Усилия не стоят профита?

В моём представлении либе это будет на пользу. Думаю, что большинство пользователей Cicerone используют MVP, и так или иначе либо мучаются, доставляя результат в презентер из фрагментов, либо пишут свои самописные решения, которые сводятся к чему-то одному

This result will be delivered to a FragmentResultListener that is called given to setFragmentResultListener with the same requestKey. If no FragmentResultListener with the same key is set or the Lifecycle associated with the listener is not at least androidx.lifecycle.Lifecycle.State.STARTED, the result is stored until one becomes available, or clearFragmentResult is called with the same requestKey.

Если слушатель открывает экран через add то сработает сразу, а если через replace, то отложиться на потом (когда фрагмент(слушатель) вернется в State.STARTED)

так то можно и свою реализацию Lifecycle написать, которая будет заходить в State.STARTED в нужный момент

про это даже в доках есть

You can also implement LifecycleOwner in your own classes.

не понял этого.

что касается гуглового резалт апи, то там просто map во фрагментМенеджере

String, Bundle

где менеджмент ключами полностью на разработчике (константами фигачим), а сам фрагментМенеджер только:

1)  сохраняет/восстанавливает резалты (бандлы)  после смерти процесса.
2) обсервит лайфсайклОвнеров и раздает резалты, когда слушатели в подходящих стейтах

По сути, алгоритм такой же, как и у навигатора с его очередью команд. Кста сам навигатоХолдер давно пора выкинуть и переписать на лайфсайкл компонентах, пусть даже и с доп. зависимостью, которая, по факту итак у всех есть.

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

честно говоря, я тоже не совсем понял твой кейс, как овнер слушателя откроет "еще один экран", если перед юзером открыт другой, который как ты говоришь специалньо не закрыли. Есть пример бизнесового юзкейса?

без понятия про бизнес кейс.
так можно сделать. а раз так, то кто-то так сделает

но теперь я вижу, что это ок

а что именно ты не понял?