Не хватает функции, возвращающей тип данных по выражению.
Если бы такая была, то её вызов для "lpad('1', 2+1, '0')||'<'" вернул бы "varchar(32765) character set ...".

IBExpert в хинте на заголовке колонки отображает тип.

Проблема ровно одна: движку нужно заранее знать какого размера выделять буфер. Верней не так... Работа с памятью в движке на сегодня устроена так, что требует не только указывать длину строковых полей в БД, но и имеет некоторые другие неудобные архитектурные последствия.
Пока не будет придумана и реализована эффективная работа с резиновым varchar, придётся считаться с некоторыми ограничениями и несуразностями. В delphi например есть оба типа, string(N) и string, причём второй со счётчиком ссылок. И работает всё крайне быстро (например при присваивании одной переменной в другую (или при передаче string-параметра в функцию) не происходит выделения памяти под строку и копирования данных, а происходит лишь увеличение на 1 счётчика ссылок).
В firebird же, насколько я понимаю, при присваивании и передаче в функцию всегда происходит alloc(+zero_allocated_memory)+move.
Всё это сказывается на отжоре памяти и тактах cpu, например при:


будут выделены и перелопачены лишние мегабайты памяти, причём не только при самом селекте, но и при сортировке. Хотя тут достаточно одного стринга длиной 3 байта, и счётчика ссылок на него.