Сделал расширение (адаптация), добавил через него реквизит справочника ( например КодНов), вставил на форму, все ок - а как обратиться к нему из внешнего отчета :
спр.КодНов - не видит и в запросе КодНов не видит

Возьми консоль запросов или СКД и увидишь, если сделал так как сказал. Потом перенесёшь запрос или схему в свой внешний отчет

(1) а через отладчик не увижу его все равно ?

(2) Если отчет добавляешь в расширении, то скорее всего увидишь

(3) из СКД не увидит никак....
(0) есть такая фича, но есть надежда что перепилят механизм расширений... когданибудь

(4) А почему у меня получалось? Может быть, это зависит от релиза платформы? Во всяком случае я через консоль запросов видел добавленные реквизиты и вставлял в отчет текст запроса.

(5) Сразу уточняй, что запрос строил в пользовательском режиме

(4) в конфигураторе при построении СКД будет ругаться на непонятный реквизит, но всю схему можно построить в пользовательском режиме, через консоль СКД и потом импортировать в конфигураторе целиком, поругается, но отстанет.
Дальше заполняем в модуле данные внешнего отчёта и будет профит

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

НО, как я понимаю, с этим есть проблема - непонятненько что делали в расширении (исправляли алгоритмы или добавляли реквизиты), а перебирать все без разбору займёт время и вроде как хорошая штука для построения запросов будет нещадно тормозить

2(6) Проблема, скорее всего, не в непонятках что именно делали в расширении. Встроенный в расширение отчет все прекрасно видит. Проблема в идеологии расширений. Они (разработчики платформы) почему-то считают, что объект может обратиться либо к реквизитам основной конфигурации, либо к расширению (включая заимствования). Внешние объекты видят только основную конфигурацию.
Т.е. надо менять идеологию - делать в подстакзках и проверках СКД доступными все объекты из всех активных расширений и основной конфиги.

(7) Так в том и вопрос - расширение спроектировано как замкнутая система, соответственно, в нём доступ текущее расширение + основная конфигурация (если есть ещё какие-то, то они не видны).
А вот реализовать доступ к расширениям в основной конфигурации (или между оными) проблема: т.к. расширение тупо можно отключить (отвалиться в непредсказуемый момент, тоже может), а код будет ссылаться на оное и поимеем проблемы на ровном месте.
Как я понимаю, потому и замкнули расширение в себе

Как появились расширения сразу возникла мысль: клиентские доработки пилить в расширениях (типа библиотечек наделать), например, расширенные функции производства в бухгалтерии, какие-то специфические доработки под особенности учёта клиента. С одной стороны красиво и можно тупо отдавать готовое решение, но при отваливании расширения - убиваются все данные им добавленные и при отсутствии нормального админа имеем гемор с восстановлением данных и надо вести какой-то учёт функционала расширений (А + Б не всегда устойчивое В)
Потому, реквизиты добавляем в саму конфигурацию, а функционал их заполнения можно положить в расширение для возможности обновлять БД стандартной конфигурацией

(0)(4)  В ETD, 1С пишет, видно прозрачно основную+все расширения. Но процессор, озу и канал до сервера надо, мое почтение.