И если kernel.org в этот транспорт не умеет то что будет?
То же самое, если попытаться связаться с тобой по телефону, если телефона у тебя никогда не было. Я про то, что git - это штука, которая синхронизирует объекты и ветки на двух машинах, если они уже смогли как-то связаться друг с другом, и git не очень интересно, как именно они это сделали.
Так же и ты можешь прочитать моё сообщение, даже если linuxtalks.co перестанет существовать. Возможно, я найду какой-то другой способ связаться с тобой, например напишу email или ещё как-то. От этого твоя способность понимать текст никак не поменяется.
это мета-команда которая потом передаёт управление в какой либо специализированный блок
Проблема не в том, из одного блока состоит программа или из разных. systemd ведь тоже не из одного бинаря состоит. Проблема начинается, когда авторы комплекта программ пытаются навязать одновременно и mechanism, и policy, лишая пользователя гибкости.
То есть если сделать git search, который делает всё, что ты предлагаешь, то придётся повторить всю эту работу для остальных задач, где полезен распределённый поиск - сделать ещё и youtube-dl search, wget --search, apt search и так далее.
Вместо этого лучше взять отдельно транспорт, отдельно систему разрешения имён, отдельно сервер метаданных, отдельно индексатор. Тогда можно будет простым скриптом в git hook вытащить информацию об объектах/ветках/коммитах и передать её в программу, накапливающую локальные метаданные. Другая программа сможет рассказать моим соседям (по DHT или ещё как-нибудь) про всё, чем я готов поделиться. И уже поверх этих компонентов можно делать глобальный поиск.

Увы, не знаю, что такое sendxml/sendjson.
Большая часть этих идей существует с времён FidoNet, когда мейлер, тоссер, редактор - отдельные программы. Сортировка и автопересылка писем там есть.
Если рассматривать классический email поверх SMTP, то есть git-send-email, а большинство MTA поддерживают .forward, откуда можно вызвать скрипт для разбора таких писем и применению патчей (git-am) из них в remote-ветки. Получателем таких писем может быть mailing list, рассылающий широковещательно письма, как это часто происходит в крупных opensource-проектах (например в ядре Linux).
Отсутствие прямой связи сейчас может и выглядит комично, но offline-протоколы всё ещё востребованы. До сих пор на Земле есть места, где связь очень так себе или появляется не всегда, а с расширением на космические масштабы проблема связи вообще становится неизбежной. Тот же TCP с дефолтными таймаутами и congestion control до Марса просто сломается.
Из интересных распределённых систем хранения (и поиска) стоит отметить IPFS, Tahoe-LAFS, YaCy. Я не знаю, как (и вообще ли) сделана в них защита от плохих участников - что случится, если кто-то будет отвечать медленно и/или неправильно.
Другая проблема в отсутствии общепринятого протокола для обмена статически типизированных данных между программами - большинство утилит командной строки в unix-пободных системах потребляют и порождают plain text, что не всегда удобно для сложных композиций. Некоторые умеют JSON, но нигде не описывают схему. Некоторые - XML. В корпорациях и модных cloud-native программах любят Protobuf (и gRPC). Для чтения людьми хороши recfiles - если бы мне нужно было выбрать формат описания артефактов для большой сети друзей, я бы начал именно с него.
Ещё интересный вопрос - что делать, если индексы очень большие, и вынуждают поисковую систему не скачивать сам индекс, а распределять пользовательские запросы на все системы, где потенциально могут быть искомые данные - насколько богатые запросы стоит разрешать? В мире веба похожую задачу решает GraphQL - он позволяет запрашивать, изменять или подписываться на изменения коллекций данных на удалённой машине и поддерживает фильтрацию и по вложенным полям, что обычно транслируется в запросы к локальной реляционной или объектной базе.