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

Doc>- интерфейс более не абстракция.
Doc>- интерфейс знает о реализациях, иначе откуда такая уверенность что дефолтный G() подходит для всех реализаций интерфейса.
Doc>- если по какой-то причине G() гарантированно подходит для любой реализации, то он может вполне себе быть extension методом.
Doc>- программист реализации может просто не заметить добавления G(), который будет не корректный для его реализации. Но в проекте IA.G() рано или поздно кто-то вызовет.

Все эти проблемы присущи и абстрактному классу, на который ниже предлагается заменить такие интерфейсы

Doc>Только это не основное свойство интерфейса. Интерфейс в первую очередь это абстракция, а теперь можно затянуть в него реализацию.
Doc>Не лучше было бы для таких кейсов ввести что-то типа "abstract base class" который бы и реализовывал такое поведение (по сути ведя себя как интерфейс с дефолтными методами)?

В C# нет множественного наследования, поэтому примерно всё делают через интерфейсы и не всегда интерфейс можно заменить на абстрактный класс.
Такой вот костыль приделали, чтобы работало и плевать, что это идеологически неправильно и портит идею интерфейсов.

Doc>А пользователю библиотеки уже выбирать наследоваться от интерфейса или такого класса.

Весь прикол в том, что я даю API в виде условного интерфейса IPlugin, через который подтягиваю в приложение сторонние dll.
Если разработчики будут выбирать что реализуют, то мне у себя писать отдельные обработчики для интерфейсов и отдельные для классов?
А дальше я обновляю интерфейс для плагинов и у пользователей лотерея, в которой половина старых плагинов работает, т.к. наследовались от класса, а вторая половина на интерфейсе сидела и поломались?