Посмотрим.

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

Я бы тоже предпочел именно такой вариант. Д.А. рассматривает как вариант существующий модуль автоматического рассчета состава при любых операциях редактирования или вручную. Но тут действительно есть проблемы:

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