именно. ведь о своих параметрах запуска только презентер В знает

это аналогично методу newInstance для фрагментов

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

конечно. а как вы себе это представляете?

говорить куда-то "я хочу перейти дальше", а там уже навигатор будет разруливать направление?
это другая концепция

она в Чичероне реализуема, но я за иной подход

это дело вкуса, но моя практика показывает, что чище выходит именно по моему варианту

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

Реальный пример. У меня есть две активити. Одна запускается стандарто, другая поверх лок-скрина девайса. Есть окно, которое списком показывает какие-то айтемы. У каждого айтема есть поле с линкой. При клике на айтем я должен отобразить контент по линке. Но
1. Если запущена стандартная активити, я должен открыть ее в браузере пользователя.
2. Если же с лок-скрина, то линка должна открыться в нашем WebView.
Сейчас реализовано так, что онда ативити всегда запускает браузер в новом таске. А вторая всегда риплейсит фрагмент  с веб-вьюшкой. А вот презентер, отвечающий за загрузку/отображение айтемов, знать не знает где линка откроется.

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

это как в случае телефон-планшет. там будет навигатор решать окрыть новый экран или открыть detailsView

не совсем. в Вашем варианте за и в новом экране, и в detailsView скорее всего будет один и тот же презентер. И сделать new DetailsViewPresenter.InitParams() вроде как нормально.
А что делать в моем? В любом случае создавать new WebViewPresenter.InitParams(link), не смотря на то, что сам WebViewPresenter может быть и не запущен? Как-то по моему, не правильно.

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

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

В общем, суть я, кажется, понял. Для передачи данных должно работать. Ну а что делать с транзишинами шаред элементов? Их-то сюда мешать не хочется.

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

Важность навигации начала набирать обороты: Realm представили свою навигацию + фрагмент менеджер Магеллан
https://realm.io/news/sf-fabien-davos-modern-android-ditching-activities-fragments/
они пошли по пути, от которого мы сознательно отказались, так как заставлять наследовать свои классы от некоторого "Screen" - это значит навязывать фреймворк

А гугл не навязывает свой фрагмент фремйворк?

даже больше, Магеллан - это еще и MVP

еще один Кондуктор, для ненавистников фрагментов