Согласен.
Если у вас два репозитория связаны, то скорее всего они должны были быть одним репозиторием.

Если интерактор1 передавать в интерактор2 для прокидывания в интерактор2 репозитория1, то может в интерактор2 просто передать реплзиторий1?

а как же "создавать репозитории под сущности, а не под фичи" ?

Не придерживаюсь этого подхода.
У меня за сущности обычно отвечают дата-сорсы.

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

Ну так создавай, но не связывай

Я считаю, что лучше провайдить интерактору две репы

у меня датасорсы, как правило: local, remote и т.д, но для одной сущности

У меня тоже. И завязаны они на конкретные сущности.

Так и все так считают. В этом практически суть интеракторов.

Это, очень даже, не плохая практика

Всё хорошо читается для понимания

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

А если из одного HTTP EntryPoint приходит информация для двух репозиториев? Как вы тогда настраиваете их взаимодействие? Через интеракторы?

Например, есть 2 кэширующих репозитория: люди и посты. В информации о человеке приходит список лайкнутых им постов, а в информации о посте приходит список полайкавших людей. На основе этой информации можно актуализировать статусы на разных экранах для разных людей и постов.

это не оч хорошая реализация rest, когда микс дата

users и topics должны быть разными точками

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

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

Я вижу только некий интерцептор, который свяжет 2 репы, чтобы они друг о друге не знали.

я же уже говорил как делаю я: две репы в интеракторе