Областью ответственности. Я придерживаюсь подхода, что одна VM отвечает за логику презентации строго одного экрана или его части. Если мы начинаем из VM делать евентбас для общения между разными частями приложения - мы добавляем ей ещё одну ответственность.
Это как тот троллейбус из булки хлеба, вроде можно, но зачем? С таким же успехом можно каждый класс в приложении унаследовать от VM) Поэтому я и говорил, что единственный аргумент за - это легкость получения пошаренного инстанса во фрагментах, если у вас нет нормального DI.

Разница в направлении взаимодействия. Общая VM — горизонтальное, на одном уровне (как следствие — потенциальная лапша в коде). Через модель (вышестоящий слой) — вертикальное. Второе — чище и гибче с архитектурной точки зрения и стратегически лучше.

а фрагмент с деталями относительно фрагмента с листом как какое взаимодействие рассматривать?  как горизонтальное или вертикальное?

В идеале — вертикальное. Но зависит от задачи. Всегда можно «срезать угол» — вопрос целесообразности.

ок что есть  есть идеальный вариант шеринга инстанса  между скринами тогда?

ок. спасибо

Почитайте дискуссию выше, там Аркадий хорошо расписал.

Если чуток отойти мыслями от экранов, то когда вы выбираете письмо в списке писем - вы просто изменяете состояние приложения, "текущееПисьмо=1553". Этот стейт кто-то может захотеть слушать, и вашему списку писем особо не интересно, кто. А ещё его может изменить кто-то вообще другой, например, клик на пуш-нотификацию. И хорошее архитектурное решение позволит вам все эти взаимодействия легко организовать. А протаскивать ViewModel в обработчик клика по пуш-нотификации - занятие мягко говоря неблагодарное. У вас там даже активити нет)
Это то, что я имел в виду, когда говорил, что shared VM из общей задачи "передать изменение состояния от одной части приложения в другую" решает только очень конкретную подзадачу: передать событие от одного фрагмента к другому.

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

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

ок. спасибо

Хм, я вроде немного другое имел ввиду) Какой-нибудь ListFragment может принимать коллбэк onItemClicked: (id) -> Unit. Предок (активити или фрагмент) передаёт этот коллбэк и открывает DetailsFragment с нужным id.

Мне кажется мы все говорим об одном и том же, только каждый немного со своей колокольни)

Ну ладно) наверно

А зачем фрагменту это? Он ведь просто регистрирует user input и сообщает об этом вью модели. ВМодель меняет состояние модели. Все ВМ подписанные на это изменение, загружают новые данные обновляя свои фрагменты.
Зачем фрагменту знать про логику обновления других фрагментов? Он должен знать только про свою view model. Low coupling, SOLID и все такое

Какому фрагменту из трёх?

Любому.

Я не понимаю Вас

Ну, в дискуссии обсуждался вариант (если я правильно понял), что один фрагмент каким-то образом может обрабатывать пользовательский ввод другого.
Это добавляет coupling. Зачем это делать, если у нас уже есть сущность, которая это делает (вью модел)?

Связность между чем и чем это добавляет?