Здравствуйте, artelk, Вы писали:

A>Название интерфейса вводит в заблуждение, согласен. Но в контракте у него прописано:
A>

A>Represents a read-only collection of elements that can be accessed by index.
A>The IReadOnlyList<T> represents a list in which the number and order of list elements is read-only. The content of list elements is not guaranteed to be read-only.

Я уже ответил, что этот пример плохой для рассмотрения и ты сам показал почему — изначально некорректный контракт. Это именно расширение, т.к. ты декларируешь две прямо противоположные вещи — список ReadOnly но в ём есть операции для модификации
Но в дотнете это не создаст большой проблемы, потому как контракт уже некорректный и используется абы как. Правильно было бы использовать такой IReadonlyList только массивах, и только таких, которые нельзя изменить никоим образом(Freezed или как там). Но в дотнете начался хаос и такую хрень распространили чуть не повсюду. Фактически, таким интерфейсом ограничиваются пермишны. Где надо обойти — запрашиваем IList и тут же модифицируем то, что по идее для чтения.

A>Допустим он назывался бы IListReadOnlyAccess, IReadableList или IListReader.

Я про контракт, он уже кривой шо сабля.

A>Мой вопрос остается в силе.

Я дал подобный ответ на примере IImmutableList — каким образом расширение интерфейса может всё сломать.

I>>Тогда такой пример — IImmutableList, который гарантирует неизменность. Всё иммутабельно и тд. А теперь наследуем этот интерфейс, скажем, IOptimizedList и вставляем туда методы FastRemove, FastAdd и тд, которые будут удалять по месту.
I>>Вроде ж всё хорошо — раз мы наследуем только интерфейс, то никаких подлянок ожидать не стоит. Гы-гы. Проверяем — передаем консумеру IImmutableList экземпляр IOptimizedList, он благополучно принимает и используем в своих целях. А мы тем временем модифицируем этот же инстанс.
I>>Итого — откуда грабли? Мы ж только интерфейс наследуем...
A>Это все очевидно и к вопросу не относится.

Это все тот же вопрос — как наследование интерфейсов может все сломать.