Ну у них там не так сильно связаны отделы, к слову

да какая разница. trademark один

ну если конановцы подсуетятся, то не вижу причин почему там может быть необъективный выбор.

нет, не нужна. потому, что потом и компилятор один останется и так далее. спасибо, не надо.

проходили

компилятор один - тоже, скорее, хорошо, чем плохо

есть второй вариант, который Паша озвучивал - стандартизация формата зависимостей

это было бы хорошо, если бы вендор стандартной библиотеки был один как в пайтоне или go. Но у нас много имплементаций стандарта, каждому вендору пришлось бы релаизовать свой HTTP клиент, со своими багами и особенностями.
Я бы вместо этого хотел иметь единственную общепринятую имплементацию с полностью определённым поведением и адекватным, возможно, стандартизированным API. При этом цикл разработки и версионность этой библиотеки вполне может не соответствовать циклу принятия стандартов С++. Новые технологии сейчас довольно быстро появляются.

и пусть реализуют

а там и стандарт можно будет за ненадобностью выпилить

есть реализация языка одна, то стандарт ведь не нужен

ну, или обновлять его будут задним числом

а я непротив иметь несколько реализаций, которые соотв. стандарту. считаю это наоборот только благом

все уже сидят на С++30, а стандарт только только приняли С++23

главное, чтобы все были строго согласно Стандарту

+, днокер стандартизнул же формат скриптов

одна реализация - всегда означает отказ от стандарта.

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

Это, как минимум, нерационально. Когда речь идёт о сложных библиотеках типа http клиента или 2d/3d графики

libcurl пилят уже 20 лет, а свежие версии выпускают раз в несколько месяцев