Формат хранения пользовательских настроек формы

[Товарищ ♂uatr]

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

ИХМО Стоит вернуться на шаг назад и задаться вопросами: "Кто этот пользователь формы? Много ли таких пользователей? Что их объединяет? Можно ли их разбить на группы? Каковы их функциональные обязанности?"
Текущее решение - одно из множества. Есть ли более удачные? Выделение отдельной формы для специфической категории пользователей, например, решит проблему?

В коробочной версии данные в контейнере лежат в рамках ключа ControlNameControlId последовательность соответствует указанной в дизайне. Меняем ключ - получаем неработоспособную настройку объекта.
Понятное дело, что можно изменить подход к "пакетированию" данных реализовав расширение к стандартной xSysLastValue (в противовес быстродействию при открытии и закрытии формы).
Но перед тем как пытаться изменить подход к упаковке данных, стоит ответить на 2 вопроса:
А какие именно действия программиста приводят к возникновению данной проблемы?
А какие именно пользовательские настройки ломаются?
С программистом, вроде, всё просто: это может быть добавление, удаление, перемещение в дизайне и переименование объекта.
В итоге получаем двумерную матрицу "Действий разработчика" на "Настройки пользователя" и отмечаем, что делать можно.