К сожалению, в ряде случае такое поведение как раз неудобное, а удобнее как сейчас без сертификата в контейнере.

Причина: отсутствие штатного механизма удаления сертификата из контейнера либо замены сертификата в контейнере. Если сертификат уже установлен, то функция cryptoapi для установки сертификата возвращает ошибку, как и утилита csptest. При различных операциях с внутренним УЦ (для аккредитованных УЦ наверно не так актуально) возможен случай когда выпускается новый сертификат УЦ на тот же открытый ключ (кросс-сертификат, например, сертификат с откорректированными адресами или сертификат, подхватывающий клиентские сертификаты при смене ключа УЦ в Майкрософт УЦ) и в этом случае оставлять "предыдущую версию" сертификата в контейнере будет не самой хорошей идеей.

До сих пор проблема обходилась экспортом в PFX и импортом обратно, что удаляло сертификат из контейнера и можно было установить новый сертификат с тем же открытым ключом. На новой версии криптопровайдера предлагается в таком случае еще и заменять/удалять сертификат в самом PFX? Либо можно сохранить некий исполняемый файл (certmgr.exe ?) от другой версии криптопровайдера чтобы "по-старому" получать контейнер без сертификата? Или можно использовать некий ключ командной строки позволяющий пропустить импорт сертификата в контейнер?

Впрочем, если большинству пользователей удобно получать контейнер с сертификатом, то пусть будет так, однако прошу реализовать идею о штатном механизме удаления сертификата из контейнера либо замены сертификата в контейнере. Хотя бы в виде отдельной утилиты командной строки, напрямую работающей с header.key. Пробовал такую написать сам, но споткнулся на неопубликованном способе вычисления контрольной суммы - удалением сертификата из ASN1 структуры получился header.key идентичный сохраненному до импорта сертификата кроме 4 байт контрольной суммы.

К слову, если контейнер связан в хранилище с другим сертификатом (сертификат 1) чем установленный сертификат в контейнере (сертификат 2), открытый ключ одинаков в сертификатах 1 и 2, то какой сертификат предполагается экспортировать в PFX? Полагаю, если будет экспортировать в PFX сертификат из хранилища, а не из контейнера, то это как раз решит проблему замены. Ну а только в случае неудачного поиска по открытому ключу в хранилище использовать сертификат из контейнера.
Что-то вроде такого:
Дано: "старый" контейнер с установленным "старым" сертификатом.
1) выпускается "новый" сертификат (кросс-сертификат) на тот же открытый ключ;
2) "новый" сертификат устанавливается в хранилище, со ссылкой на тот же "старый" контейнер;
3) "старый" сертификат удаляется из хранилища для однозначного поиска по открытому ключу в хранилище;
4) экспортируется PFX с сертификатом из хранилища (в данном случае найден "новый" в хранилище);
5) импортируется PFX и получаем "новый" контейнер с "новым" сертификатом, плюс меняется ссылка на контейнер в хранилище;
6) тестируем "новый" контейнер и при необходимости удаляем "старый".