Ну кто так строит.....

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

Итог - надо понимать, что каждому модулю соотвествует своя версия библиотеки, в unix думаю также, просто библиотеки наверное пореже обновляются.

Довольно часто разработчики интерфейсов скрывают работу с памятью, чтобы просто не требовать от клиента соответствия crt. Тогда надо либо давать доступ к аллокаторам, брать управление памятью на себя, либо наоборот давать пользователю переопределить аллокаторы, либо например вообще не давать управлять памятью пользователю, вобщем много вариантов.

Если посмотреть на всякие API к приложениям, то обычно такие варианты:
* COM style - не обязательно COM, но по сути есть фабрика классов, сам ты ничего не конструируешь и не удаляешь
* полный доступ - дают наследовать и прочее, обычно требуют точного соответствия crt debug и crt release
* переопределение alloc/free

>> И я привык, что в исполняемом образе (после динамической линковки) будет один malloc(), один free() ну и так далее. <<
Так ведь маллок/фрии связываются статически. Разве нет ?

PS: if(p) free(p) - здесь if() избыточный. free() не падает по NULL. это стандарт.

Так всё верно, free() действительно будет не тот и это действительно забота того же самого код, который выделил память, её и освобождать.
А как вообще можно ожидать, что в другом модуле он будет "тот"? free() - это ведь не API операционки, это API ран-тайм библиотеки, поддерживающей ваш конкретный модуль. А если ваш модуль цепляют к другому языку? Там свои ран-тайм библиотеки...
Хотите универсальности? Пользуйтесь API операционки, какими-нить HeapAlloc/HeapFree всё будет как ожидается...
Это в юниксах почти всё собирается из исходников, если я ничего не путаю - почти всегда на с/с++ и всегда с одной системной ран-тайм библиотекой (скомпиленой под конкретно вашу операционку). А на винде миллион компилируемых языков и систем их поддержки. Забиваться на какую-то одну среду означает сразу сужать область использования своей разработки. Вот вам и ответ, кому нужны эти три строчки кода... Это нормальная инженерная практика, снижающая зацепление компонентов, - "где выделил, там и освобождаю", поэтому VC не ожидала такого подвоха ;))

Насчет веревок и ноги не понял?

При разработке принято изолировать код на модули - это просто архитектура и дизайн. Естественно в рамках одного большого проекта модули скорее всего будут поддерживаться параллельно и везде все будет на одной crt и нативно юзать классы как хотят. Но какие-то проекты могут быть сторонними или по каким-то иным причинам быть в другом окружении - вот тут надо думать обо всех этих проблемах. Плохо что сама среда c++/с никак тут не помогает. В managed языках я думаю такой проблемы быть не должно в принципе - нет совместимости нет компиляции.

Почему-то во всех остальных распространненых системах не стесняются при апдейте ЗАМЕНИТЬ версию libc на более новую.
И ничего не ломается. В Solaris вообще у меня программа скомпилированная в Solaris 9 прекрасно работала в Solaris 8 с его более старой libc. (ну то есть я знаю какие функции надо было подергать, чтобы не работало, которые раньше были в отдельных библиотеках, а потом их в libc внесли. Но если их не использовать...)

Наоборот так побороли DLL hell - каждая программа строго привязана к crt библиотеке, манифест всегда внедряется внутрь DLL/EXE и описывает эту привязку. Библиотеки сейчас лежат не в одной куче в system32, а ставятся в winsxs, где четко описаны версии. Даже библиотека с одним именем может иметь несколько вариантов и это правильно, только тогда гарантируется точное совпадение окружения с тем что было при разработке.

Я проверял, вызов ядра из HeapAlloc (ntdll!RtlAllocateHeap) происходит редко.
Там реализован немаленький user-mode memory manager.

"нормальной практикой" это было бы сто лет назад, ещё до изобретения колеса ООП. А теперь это - вопиющаяя безграмотность, поскольку нарушается "инкапсуляция" и прочий полиморфизЬм.
Особенности реализации (и уж тем более члены класса) наружу не выставляют. это моветон и разбрасывание граблей.

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