> в С++ большой

Стандарт. Плюс он написан так, что часть вещей просто UB, часть отдана на откуп реализатором компиляторов.
Это всё нужно держать в голове при написании даже самого просто кода.
И на это тратится время и внимание (которое тоже ресурс) программиста.

> И, затем, совершенно сознательно не сделаю double free.

О, как самоуверенно.
Ну или у нас тут человек, который не совершает ошибок.
Или кто-то что-то недоговаривает.

> Ну т.е. один и тот же процессор способен выполнять... непредусмотренные изначально инструкции

Вы ушли куда-то далеко. Мы говорим про инструкции самой программы. Что у вас для гарантии должна быть проверка на null, и если вы ее добавляете, то она будет в результирующем бинарнике. А в расте при тех же гарантиях проверка не нужна.
А если вы на проверку забьете - то это ваше дело.

> При этом опять же совершенно сознательно, где нужно (а бывает и такое), для ускорения работы не буду использовать примитивы синхронизации.

А как вы гарантируете что к этой переменной не будет обращения с другого потока?
Дайте угадаю - вы просто все продумали и пришли к выводу что эта ситуация невозможна? (т.е. по факту "мамой клянусь!")
Но тут есть ваш коллега, у которого другое мнение на этот счет))
А потом Сaptain "That should never happen" strikes! Again...
и у нас очередная уязвимость из-за гонки.

> может и не готов для "повседневного" использования, но в принципе уже рабочий.

Это немного не так. Но раз вы не в контексте, то нет смысла это обсуждать.
Когда они его допилят, тогда вернемся к этой теме.

> По вашей ссылке - пустота.

По всем четырем?? Надо же.
Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-c
Результат работы msvc отличается от gcc и clang.
Получается вы берете рабочий код, компилируете под другую платформу и он начинает работать неправильно.
Странно что вы не видите в этом проблемы.

> У меня за плечами уже не одна сотня тысяч строк кода на С++

Вы же понимаете, что личный опыт так себе аргумент.

>  И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.

Да, простите. С++ники тоже не сделали такой инструмент.
Может потому что им нравится делать, а потом исправлять уязвимости (мозила и хром передают).
А может потому что они не видят в этом проблемы.
А может задача слишком сложная с теми вольностями что позволяют плюсы.
Кто знает.

> а запустить и посмотреть - где валится. И работать уже по месту.

А валится оно где попало и в рандомных местах. Потому что память в этот момент уже испортил кто-то другой просто выйдя за границы буфера. И какую именно память он попортит в след. раз никто угадать не может. А еще это повторяется отнюдь не всегда.
Ну удачи, расчехляйте санитайзеры.

Несмотря на то что сейчас я не с++ программист, мне доводилось исправлять такие баги. И больше не хочется))