B>Обе статьи об одном и том-же разными словами. Причем тут .NET не очень ясно... Я говорю о локальной компонентной технологии, а не о распределенных вычислениях, сервисах и иже с ними (хотя она может и должна будет потом использована в этих областях). Как я подчеркивал в статьях, все т.н. "компонентные технологии" подразумевает повторное использование компонентов в неких алгоритмических языках. В случае SOD алг. язык не нужен, хотя и может быть использован. Что-то я такого в .NET не припомню...

А причём там Java и COM? Java — это язык программирования, COM — это способ написания программ [Роджерсон], .NET — это Framework, или виртуальная операционная система[Gates]. Ничего общего нет, а компонентная парадигма программирования заложена только в COM, CORBA и ещё что-то в .NET только я названия точного не помню.
Теперь о таких статических компонентах. Они уже и сейчас есть: ActiveX называются. В любом случае Вам придётся где-то хранить описание интерфейса, так что вернётесь к IDL или придумаете что-то своё, результат один. Далее: предположим у Вас есть уйма готовых компонент, из них Вы собираете программу. Программа — это некий исполняемый файл. То есть либо Вам надо его компилировать, либо иметь готовое host-приложение, то есть всё равно надо что-то да писать на алгоритмическом языке, по меньшей мере скрипт сборки. Далее: сами компоненты друг с другом общаться не будут, даже имея для этого интерфейс, то есть кто-то должен "толкать" их к взаимодействию посредством алгоритмического языка.
В любом случае то, что описано как SOD уже нашло отражение в так называемых Web Services.

А .NET — это как раз и есть огромный набор готовых классов (класс есть компонент, но не наоборот), бери и собирай готовое приложение... на C#, например. Очень милый язык. Так почему же люди все не бросаются в .NET, где вроде бы столько всего вкусного (одна работа с XML чего стоит, легко и просто, не то что используя MSXML)? А ответ простой — никто не хочет иметь дело с компонентами третьих сторон. "Ну не нравится мне ваш tab control!!!" — и это ещё только начало. Так что теория это всё, теория...

B>У клиента — public member умный указатель, который называем "клиентский разъем". У сервера — public member умный указатель, который называем "серверный разъем". Перегружаем операцию "какую угодно" для присвоения клиентскому разъему значения серверного. Вот так все просто, и никаких .NETов не надо... Все происходит в рамках одного приложения (хотя это не имеет особого смысла "в рамках одного приложения")

Я бы Вам советовал прочитать книгу Роджерсона "Основы COM" он там на полном серьёзе говорил, что если б у него был стыковочный модуль (интерфейс) на крыше дома (сервер), то он мог состыковаться с советской станцией Мир (клиент) и он прав. А зачем это нужно, если нет чего-то что нужно было бы передавать через этот стыковочный модуль?
То есть Вы решаете проблему стыковки, но не проблему взаимодействия. Его кто-то должен будет писать, так что вернёмся к тому что имеем.

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