Обычные интерфейсы не имеют никакого смысла.
Вы либо будете делать иерархию наследования интерфейсов и столкнетесь с теми же проблемами, что и в классическом ООП.
Либо вам придется делать что-то вроде множественного наследования. И при этом гибкость будет меньше чем у утиных интерфейсов.
Это же очевидно. Вы не получите чистую абстракцию другим способом.

Кроме того, предложенное - это дополнение к классическому ООП.
Т.е. в языке будет полная свобода по реализации любых динамических вещей и при этом будет три уровня эффективности:
1. Статические методы (вернее обычные процедуры)
2. Динамические методы (обычные методы Oberon 2)
3. Абстрактные методы (интерфейсы)

Фигачим в основном на уровне 2. Когда нужно чуть эффективнее, то спускаемся на уровень 1. Когда нужно чуть гибче, то поднимаемся на уровень 3. Да это блин идеальный язык будет.

2 Илья:
Я думаю, что формулаодин метод == один интерфейс- это таки самое правильное понимание сути утиных интерфейсов.
Это и объясняет всю их гибкость. Мы редуцируем обычные интерфейсы до элементарных с одним методом (хоть это и не очевидно по синтаксису). И сама по себе реализация метода интерфейса и есть заявка на поддержку. То, что в Go интерфейс объявляется с несколькими методами - это чисто оформительная штука для человека.
Мне казалось, что это все понимают...

> -- Цитата:
> В порядке бредогенерации...
Если честно, то слабо понял. Можешь немного развернуть мысль?