Cyberax,

LCR>>Diamond-проблему как раз трейты решают, и это решение модульное, типобезопасное и непротиворечивое (см. статью Scalable component abstractions). Соглашусь, что несколько громоздкое из-за правил линеаризации. И ограничения есть — нетривиальные конструкторы недопустимы. Впрочем, если мы хотим позволить себе конструкторы с параметрами, тогда придётся навернуть систему типов и отношений между классами.
C>Вот только оно неудобное. Конструкторы реально достают, к примеру.

Как говаривал Нильс Бор, "Да, согласен, моя теория безнадёжно плохая. Предложите лучше."

На данный момент ввести конструкторы для трейтов (с разрешением вызова в порядке аналогичном линеаризации — это уже неоднократно предлагалось) означало бы поставить крест на дальнейшем развитии. Кто знает, может быть кому-нибудь из команды разработчиков придёт мысль обобщить отношение extends или with так, что проблемы с инициализацией уйдут в небытие По крайней мере, сейчас есть 3.5 известных мне способа обойти проблему с конструкторами в трейтах — можно подобрать подходящий.
(Вон в джаве сплошь и рядом лепят метод initialize, и ничего, считают это паттерном даже...)

C>Diamond-проблема на практике во многом надумана, она встречается раз в пятилетку. Поэтому стоит ввести какое-то поведение для неё, но не трогать самые частые случаи использования наследования — частичные mixin'ы.

Я бы сказал несколько иначе: мы научились жить в кандалах, однако раз в пятилетку очередная примерка новых кандалов вдруг переполняет чашу терпения.

На самом деле каждый из нас чуть ли не ежедневно сталкивается с последствиями неудовлетворительного решения Diamond-проблемы:

1. Существование интерфейсов как сущности — нафиг бы они сдались, если бы можно было оставить полноценные классы

2. Постоянно встречающийся совершенно дурацкий паттерн MyInterface <- MyInterfaceImpl, с единственной (!) реализацией. А почему нельзя просто использовать класс MyInterfaceImpl? Ну конечно, вдруг получится, что надо наследовать от чего-то ещё и от MyInterfaceImpl, и мы окажемся в неудобном положении тогда.

3. Якобы best practice "никогда не наследуйте реализацию, используйте делегирование". Ребята, а в чём проблема-то, если можно всегда отпочковать наследника, подмешать нужный функционал из других классов, переопределить что надо и вперёд? Увы, с интерфейсами и одиночным наследованием такой фокус не провернёшь, вот и вылезла "бест практика".

4. Ну и просто сплошь и рядом дубликаты одного и того же кода — просто потому что некуда или нельзя выделить повторяющийся функционал.

Дискасс, или всё и так очевидно?