Собственно дело в чем.
Если выполнить эту команду и в базе есть объекты измененные расширениями, то допустим она показывает, что есть документ _Document1108X1 - типовой носил имя _Document1108
А у документа есть индекс _Document1108X1_1
Ты такой развеселый лезежь в скуль, а там у документа нет такого индекса... Но есть _Document1108_1X1
Пилю обработку по работе с индексами, анализ, реиндексация все дела и тут такая фича, обработка ноги сломала.
Есть нормальное объяснение почему такой прикол?

Попробуй реструктуризацию расширения сделать

Куча идей для тестирования:

Если добавить еще одно расширение и там с индексами поиграться?
Если первое отключить, добавить его еще раз уже третьим (что будет с первыми двумя в структуре и SQL)?
Удалить расширение, заново добавить, постфикс будет также отличаться?
Самому добавить дополнительные индексы в конфигураторе (КОРП режим).

(1) зачем? База работает прекрасно. Обращения к данным идут без проблем.
Имена индексов в самой СУБД корректны.
Они такие же как и у прочих объектов.
_ИмяНомер - типовые
_ИмяНомерXНомер - если расширения есть на объекте

И только лишь указанная функция как по мне фирмой 1С криво написана. Попутали местами вывод этих XНомер

Вот еще шляпа найдена...
Тут по документу не прошлись расширения, а имена индексов по факту не соответствуют тому что выдает указанная выше функция.

Придумывать функцию с названием Получить.. или другим императивным глаголом - плохой стиль. Даже в каких-то рекомендациях по программированию от 1с так было написано. И в то же время архитекторы платформы сами такое допускают. Удивительно.

ОФФ.
(5) >> архитекторы платформы сами такое допускают...

Уж миллион раз обсуждали.
Авторы платформы, авторы рекомендаций и авторы типовых конфигураций - это непересекающиеся множества авторов.
Иногда друг с другом они наверное общаются (хочется верить), но вряд ли тратят это время на обсуждения стилистических нюансов имён функций языка 1С.

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

Погуглил уже после того как, о проблеме заявил, и понял, что этот вопрос уже ни один раз тут на мисте поднимался и видимо никто 1С не продавливал исправить ошибку)))

Попробую руками консов 1С продавить, самому противно уже писать в 1С

(4) Печалька, делайте соответствие по полям индекса.
Тогда на все приколы наименований индексов будет по-барабану.

Ответ от ИТС
Ошибка уже зарегана, ждииииииитттииииии
https://bugboard.1c.ru?state=prj-plt8gen-er-60026177

(9) Хорошо, в 2035-2045 году выкатят обнову, что-то пойдет не так и снова 8 лет ждать