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

Чтобы в рамках тестов получить result как объект для верификации

кмпп?

Котлин мультиплатформ

это я понял, только при чем он тут?

к либе наверное не относится никак, но сам подход с передачей данных через фрагменты плохо вписывается

так фрагменты на другие платформы вообще не вписываются 🙂 я больше про это

я теперь на все смотрю с точки зрения шаринга кода🌚

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

можно создать отдельную либу экстеншен для этого, кому нужно будет тот заюзает

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

судя по доке можно и от чайлда к перенту
https://developer.android.com/training/basics/fragments/pass-data-between

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

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

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

Касательно описанного выше кейса, на мой взгляд ничего критичного не случится. В 99% случаев разработчик это заметит и закроет экран вручную. В 1% случаев описанное поведение возможно будет использоваться намерено.
Надо решить оставить такое поведение, либо всегда при отправке результата назад закрывать текущий экран. Возможно второй вариант будет у всех и всегда, потому что вряд ли нужно скрыто отправлять результаты.

А что не так с аля Гугл?

не надо уводить дискуссию

пожалуйста

Ну а про возврат результата хорошо бы  чтобы публичное апи не поменялось. То есть чтобы при обновлении библиотеки ничего не сломалось для тех кому не нужен for result api.