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

Q>Основная мотивация, стоящая за default interface methods — чтобы можно было добавлять методы в интерфейс, не ломая компиляцию существующих имплементоров.

Хм... а это что за идиотизм?? С чего бы это изменённый предок "не должен" ломать наследников? ЕЩЁ КАК ДОЛЖЕН!!
Если у тебя класс "ГеомФигура" и ты помимо "Площадь" добавил метод "Периметр", все наследники обязаны реализовать правильный метод "Периметр"!
Собственно, потому интерфейс и является КОНТРАКТОМ, что там нет "отлынивающих классов" — любой из наследников ОБЯЗАН корректно реализовать контракт.

Q>Если ты автор библиотеки и добавляешь в интерфейс метод, то раньше у тебя все пользователи, реализующие интерфейс, ломались; и им нужно было определить у себя добавленный метод.

Это в джамшутской терминологии "ломались". В нормальной: "все наследники получали корректирующую ошибку о недореализованном методе".

Q>С добавлением default interface methods — нет, больше не ломаются, и явно реализовывать новый API им не требуется.

Спасибо, б%%%! Мало нам таймбомб — давайте теперь ещё и эти.

Q>Если по умолчанию разрешать вызов без приведения, то добавление нового метода Method() сломает компиляцию, то есть defeats the whole idea.

Не надо про УСЛОВНЫЕ СЛУЧАИ. Есть процесс разработки. Если у тебя есть библиотека и она обновилась, там всегда есть breaking changes. Хочешь — не обновляйся и ничего дореализовывать не надо. Хочешь свежачок — компильни, проверь ошибки, дореализуй контракт. Всё. Просто как день. Здесь не идёт вопрос об обратной совместимости — это эволюция продукта, где допустимо улучшение, требующее правки чужих исходников.