Уточнил, там речь конечно по смерть процесса. Смену конфигурации кто угодно переживет

после восстановления процесса стек навигации все равно разматывается и аттачатся все фрагменты

поведение ,что вы описали точно справедливо для нескольких активити

Вьюмодели не создаются. Как и все остальное. Только при возврате назад. Проверьте. Пол года назад так было, и уверен, что так и есть. У этого есть разумное объяснение: у вас бы восстановление сто лет было бы

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

Так как это общее заблуждение, то полезно донести до многих 👍

Кажется, я даже на каком-то докладе про это говорил, но уже не помню контекста

стоит отметить, что ВМ можно создавать по разному, у меня, например, без фактори, руками в онАттач или онКриейт фрагмента,  возможно у кого-то там лейзи на перый геттер

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

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

Для этого достаточно Result сохранить в бандл через хук в Navigator

и после отдать как возможность, и по возващению данные восстановятся

если добавить пример с реактивной моделью и чётко написать об этом в readme, то можно оставить эту фичу.

Раз вернулись к истокам с передачей результата, возникают мысли про dialog fragment'ы. Я знаю про твой (можно на ты?) взгляд на работу с ними, что они не относятся к навигации.

К чему я, нет ли какого-то способа заменить работу с ними через targetFragment на решение с Cicerone? например, добавить возможность работы с ними отдельными командами, без цепочек, без взаимодействия со стеком, но чтобы можно было передавать результаты. У нас сейчас в проекте по ощущениям больше половины мест, где общаются фрагменты, это DialogFragment или BottomSheet.

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

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

+, учитывая также связь между child и parent fragment

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

а Navigator может в таком случае сохранять ещё и Result, как он делает это с очередью комманд, только Result будет ещё и через bundle

Надо учитывать смерть процесса - сделают через реактивную модель, в остальных случаях (коих большинство) достаточно текущего решения