Не будем забывать, что clean - это прежде всего, простота разработки и поддержки кода.
Если возникает необходимость полдня чесать репу и думать что куда поместить - то нафиг тогда этот clean?
По опыту репозиторий лучше воспринимать как тонкую обертку (=data source).
Объясню почему.
Вот вы, джедай клина, пишите репозиторий, который объединяет 2 дата-сорса (net и db). Ok, всё круто.
Потом приходит другой разраб. Ага, надо перед запросом прочитать настройку. Чешет репу, куда поместить дата сорс настроек. Аха, настройка связана с данным запросом, значит в репозиторий. Потом другой разраб хочет ещё один запрос сделать. Чешет репу, добавляет в тот же репозиторий. Третий разраб хочет ещё писать настройки ..

В итоге в репозитории получаются инжнкекты левых дата-сорсов, других репозиториев и другой хрени.
А потом... Этот репозиторий понадобилось переиспользовать, но без настроек. Что делает 4-й разраб? Правильно, добавляет флажки в параметры методов. Или того хуже, добавляет state в репозиторий.

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

В данном случае речь про установки:
"Репозиторий может объединять дата-сорсы" и
"Репозиторий абстрагирует один дата-сорс".
В первом случае возникает вопрос: "Какие"? Во втором случае вопросов не возникает.

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

Репозитории - это слой данных. Его имплементация может быть вообще в отдельном модуле. И он как раз может переиспользоваться. Сущность, которая работает с несколькими дата-сорсами (репозиториями) - это скорее интерактор, но на самом нижем уровне. В бизнес-логике может быть несколько слоёв. На нижнем уровне может быть интерактор, который работает с несколькими репозиториями. Но этот слой уже принадлежит фиче, а не имплементации репозитория

Репозитории - это слой данных. Его имплементация может быть вообще в отдельном модуле. И он как раз может переиспользоваться. Сущность, которая работает с несколькими дата-сорсами (репозиториями) - это скорее интерактор, но на самом нижем уровне. В бизнес-логике может быть несколько слоёв. На нижнем уровне может быть интерактор, который работает с несколькими репозиториями. Но этот слой уже принадлежит фиче, а не имплементации репозитория

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

Я говорил о том, что каждая фича в своем домене держит один или несколько интерфейсов репозитория, под каждый кейс. Без переиспользования. Надо сохранять данные - один репо. Надо сохранять еще и настройки и т.д. - другой.

Где имплементация этих репозиториев?

Вот это и не хорошо. Потому что дата живёт отдельно от фичи.