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

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

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

Когда у вас будет библиотека хотя бы с сотней тысяч пользователей, попробуйте поломать базовый интерфейс.
А если счёт идёт на миллионы строк кода как в интерфейсах .NET?

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

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