На самом деле всё уже не раз проговаривалось, и обсуждать даже и надоело, но всплывает снова и снова. И нет уголка с табличкой, куда ткнуть любого желающего. (Или я уже забыл?)

Обычные обсуждения ООП (ссылки на Кауфмана дают свежий пример) оставляют странное впечатление:
вбрасываются слова вроде "объектная декомпозиция", налетают любители условного дзена (псевдофилософской болтовни), и пошло-поехало.

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

Вот и с ООП: есть базовые технологические императивы, выявленные (фуфффф) в Модуле-Обероне, и ограничивающие дискуссию по ООП:

Императив №1.Нужны модули. Раздельно пишомые разными субъектами, договорившимися про интерфейс, и пишомые так, чтобы друг другу не мешать (всё остальное следует отсюда). Никуда от этого не деться -- Природу не обманешь, никто и не сумел.

Императив №2.В сложных задачах неизбежно возникают динамические структуры данных, в которых возникает проблема -- отделить сложную общую функциональность по управлению структурой от специфики по информационному наполнению.
"Расслоение функциональности по модулям." Отсюда однозначно вылазит однопредковое наследование в том виде, в каком оно практикуется в Оберонах.

(Про централизованный сбор мусора не говорим, это здесь деталь и подразумеваемое автоматическое следствие.)

После установления императивов-ограничителей болтовни можно дать волю фантазии.

1.
Возможны варианты оформления и реализации "расслоения функциональности", ср. классический Оберон и КП, но это варианты в рамках ограничений двух императивов. Два минималистичный подмножества -- классическое и с наследованием только от ABSTRACT (подмножество КП). Интересно понять ограничения обоих.

2.
Далее имеет смысл вести "общефилософскую" дискуссию хоть про объектную декомпозицию, хоть про множественное наследование -- но уже с пониманием того, что при обсуждении в установленных фундаментальных ограничениях само собой произошло разделение:

ООП-0 как технологический инструмент (взгляд снизу).

ООП-1 -- разные фантазийные схемы организации структур данных, включая штучки в духе множественного наследования и т.п.
Но при этом сразу ясно, что это сложные, громоздкие, сильно неоднозначные и потому совершенно-неочевидно-что-универсальные вещи. И что обсуждать такие вещи (то же множественное наследование) нужно в духе рассуждений о сложных структурах данных, имея при этом в виду отображение на уровень реализации -- ООП-0, жестко ограниченный базовыми императивами.