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

Зайти и посмотреть включена возможность или нет, для чего выгрузку делать? Если включена, опять таки, для чего выгрузка? Сравнить с конфигурацией поставщика не проще?

(0) жёлтые замочки и значочки не?

(1) Нужно программно узнать.
Есть расширение, которое привязано к типовой конфигурации. Если же конфигурация изменена, то нужно делать адаптацию.

ТС сам себе трудности создает и героически их преодолевает.
Молодец, чо.

(2) Программно их как-то можно получить?

(5) традиционно - зачем?

(6) см. 3

Ещё варианты:
- у расширений есть метод ПроверитьВозможностьПрименения(), но он не учитывает того, чтобы могут быть ДОБАВЛЕНЫ объекты метаданных или изменены модули.
- есть метод ПолучитьИдентификаторКонфигурации() - но это закрытая книга.
- ещё есть ПолучитьСтруктуруХраненияБазыДанных(), но это только структура, про изменения модулей не узнать.

ещё варианты:
- хэш суммы у cf-ников у разных конфигураций одного релиза различаются

в (9) точнее сказать так
- хэш суммы cf-ников у разных баз с одинаковой конфигураций различаются

(10) Извините, но мне кажется, что такую возможность авторы системы расширений скорей всего не сделали - как всегда или сроки или тупо не предвидели что это нужно.

(11) ну и пусть не сделали, наверняка есть другой способ.

Проверил ещё один вариант
- /CompareCfg в пакетном режиме между основной конфигурацией и конфигурацией поставщика. Для конфигураций без возможности изменений возвращается "Конфигурация 'Конфигурация поставщика' недоступна"

Остановлюсь пока на этом способе.

А что твое расширение сразу ломается, если были доработки конфы?

Или это способ поднять бабла?
-ААА у вас доработанная, а нука выложите за про версию моего расширения 100тыщ куе

(15) Да)

(16) Проще счётчик в расширение добавить. Каждые два месяца после последнего посещения выдавать сообщение "Пора подправить Расширение. Сообщите, администратору базы" ))

а что у расширений можно код закрыть?

(18) вынести код в dll?

(офф) всегда есть шанс после любого обновления рвать волосы... эээ... на голове, бить себя в груди и "Мамой клянусь - работала же!!!" - всё бесполезно... пара, тройки обновлений и как бог - черепаху, мама родная не узнает... зачем автору знать были ли изменения? :)

Если в расширении пара, тройка справочников и документов, то там же можно метаданные сравнить с эталонными.

(20) Зачем, зачем... А потому что )
Позже расскажу. В другой теме.

Вопрос поставлен "Как?"

(22) Как, как... в (21) вариант ответа. Если исходить, что тебе не важны изменения, которые тебя не касаются.

Есть ещё один вариант контроля за идентичность конфигурации (не важно типовая она или с изменениями). В распределенных информационных базах используется механизм регистрации изменений конфигурации - в сообщениях обмена РИБ используется контрольная сумма конфигурации.

лучше подходи к ценообразованию по другому

типа бесплатные обновления на год и тд и тп