Один и тот же запрос к справочнику с иерархией элементов, на 8.3.7.1790 и 8.2.19.76 даёт разный результат.
текст:
"ВЫБРАТЬ
        ПодразделенияОрганизаций.Ссылка,
        ПодразделенияОрганизаций.Код,     
        ЕСТЬNULL(ПодразделенияОрганизаций.Родитель.Код, """") КАК РодительКод
    ИЗ
        Справочник.ПодразделенияОрганизаций КАК ПодразделенияОрганизаций"
в 8.2.19.76 пустой РодительКод = ""
а в 8.3.7.1790 пустой РодительКод = "        " где число пробелов равно длине кода.
что-то я в замешательстве.

на обеих платформах режим совместимости с 8.2.13

(0) Сама база одна?

ИМХО. 8.3.7.1790 более правильный результат дает. Ибо NULL там нету.

Лучше такое поле в запрос добавь:
ПодразделенияОрганизаций.Родитель.Код есть null КАК ЭтоNull

(3) да, базы - копии.
(4) ПодразделенияОрганизаций.Родитель.Код есть null КАК ЭтоNull да, считает что они NULL

При этом на новой платформе поле ЕСТЬNULL(ПодразделенияОрганизаций.Родитель.Код, ""test"") КАК РодительКод
возвращает "test     "

(5) А вот с этим, я бы в 1С письмо написал.

На 8.3.7.1805 проверил - то же самое (добавляются пробелы)

Это фича, ибо в СП к "Функция ЕСТЬNULL":
Второй параметр будет преобразован к типу первого в случае, если тип первого параметра является строкой или числом

Выходит, в 8.2 поведение было более ошибочно, чем теперь (теперь квалификаторы строки учитываются)

(9) Это лишний CAST, нафиг не нужный.

(10) Что-то мне подсказывает, что приведение типов значений колонки результата запроса к минимально необходимому выполняется на стороне сервера 1С (т.е. после получения результата запроса от СУБД)

А ты проверь, чтоб не гадать :)