> Я так подозреваю, что ядро на голой сишке писали, чтобы не было никакого неявного кода.

Никакого -- утверждение слишком сильное для сишки. Как минимум из-за неявного преобразования типов.
Впрочем, по сравнению с крестами, я склонен согласиться: с крестами неявного кода было бы на порядки больше.

> По сути всем понятно, что любой ООП можно реализовать и без поддержки ООП в языке. На структурах и прописывая весь скрытый в ООП код ручками.

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

А так, как описываете Вы, ООП успешно добавляется в более высокоуровневые языки: Lisp-ы, ML-и, тот же Perl вон... То есть поинт тут в том, что так делать удобно только в случае использования языков более высокого уровня: причём крайне желательно, чтобы они обладали встроенными инструментами изменения своего синтаксиса.

> Так возможно получится быстрее. Немного. Ну самый простой пример это managed строковые типы. Они безопаснее. Но они требуют динамического выделения памяти буквально на каждом шагу. А это на самом деле лишние тормоза.

О том и речь: высокоуровневым языкам -- высокоуровневые задачи, и наоборот.

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

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

По части самого вопроса, тут на самом деле ни черта не ясно, зачем это нужно. Как бы, крестовики спокойно могут и на голом си написать модуль, если им потребуется, ибо всё-таки в некотором смысле одно является субсетом другого. Так и зачем тогда напрягаться, поддерживать какой-то дополнительный интерфейс? Статус-кво вполне удовлетворяет нуждам проекта.