> Тогда не понимаю проблемы. У сервера шины просто нет таких данных, что
> нужно передавать гигабайтами.

У него нет, у клиентов могут оказаться. Да, пусть в нештатном режиме работы, но всё-таки лучше чтобы они прошли, а не подропались.

> Система UNIX изначально рассчитана на работу в рамках одной машины PDP-11. Уже
> два процессора - выход за пределы изначальной концепции. Сетевая прозрачность натягивается
> с трудом - сравните с plan9.
> Поэтому какие-то высокоскоростные механизмы передавать наружу не очень получится. А тем
> более, такую сложную шину, которая должна сочетать мощность передачи, удобство использования
> и мириады разных потребителей с совершенно разными скоростями (от скриптов bash
> до передатчиков Гб/сек).

Тут пока никуда не денемся (да и у нас не UNIX, и "изначально" было 40 лет назад:-)
И повторюсь, Гб/сек штатно (24/7/365 кто-то кому-то что-то шлет таким темпом) не надо. Но осиливать недолгие всплески имхо значительный плюс.

> Я сомневаюсь, что это улучшение. Какие минусы решения:
> 1. Сложность использования и поддержки.

Смотря как завернут. Теперешний d-bus разве сильно отличается?

> 2. Упадёт надёжность ОС - чем больше ядро, тем меньше надёжность.

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

> 3. Быстрая DBus будет провоцировать неправильную архитектуру программ, гоняющих по ней
> видеофайлы.
> Если будет "мы постараемся передать всё", то люди будут слать гигабайтами.

Не аргумент имхо вообще. Ну придется стрелять в скрипачей, как обычно. Они что, кроме этого не найдут что испортить? :-)
Все мы знакомы с ОС, которые ради заботы о юзере задают побольше ограничений и вопросов. И что в итоге получается.

> Более-менее всегда, если на шину наложены строгие ограничения. Если сказано, что шина
> гарантировано не передаст ни при каких условиях больше 10 SMS в
> секунду.

Не, это вы про out. А я про in. Если они не знают, сколько SMS им повалит в след. секунду, им сложно принять решение открытия отдельного производительного интерфейса.

> С текстом общаться, как известно, относительно легко работать на любом языке программирования даже без специальных модулей.

Ага, снова работа со строками на С :-) sizeof()-1 или не -1, указатель еще разок передвинуть, или уже всё, ставить в конце \0 или он там и так будет, изменил отправитель отступ в новой версии или оставил...
Но неважно, библиотеку вылизать можно.