Да,
проверил StrCatM и стандартный StrCat - результат совершенно одинаков = 56 320 байт .
------------ Дoбавленo в 16.59:
Ну так о чем мы спорим о том, что накопление с разделителем лучше делать в FormatStr ? (твое предложение кстати)
или так (сколько здесь лишних байт - не считал)

совершенно не верно. Чем больше готовых функкций (компонент), тем больше вероятность что новичок не найдет того, что ему нужно. Тут начинать надо с хорошего интерфейсного решения по доступу к элементам через палитру.
------------ Дoбавленo в 17.15:

выражаю сомнение в истинности результатов проверки. Еще по предыдущему итогу можно было понять, что код программы выравнивается на границу в 512 байт (это минимальный объем данных, который может быть получен с жесткого диска), а значит при увеличении или уменьшении программы на величину меньшую области резервирования изменения размеров наблюдаться не будет.

Dilma, размер файла получал компонентом FileAttributes. Что он считает не вникал.
TC выдает такие же данные и если, например, для файла Settings.cfg показывает 22 байта, то наверное и для этих не подгоняет.
Хотя для exe-файлов подгоняться вроде должно.

Tad, выше речь шла о формате PE файла, а не о способе записи файлов как таковых. Предлагаю провести простой опыт: создать новый проект и у формы в св-ве Caption изменять надпись от 1 до 512 байт, замеряя размер итогового исполняемого файла после каждого изменения.

Надеюсь данные из окна "Отладка" тоже о чем-то говорят
StrCat - 41 960 bytes code
StrCat+Delimiter - 42 016 bytes code
FormatStr - 42 604 bytes code

да, компилятор как раз выдает размер полученного кода до упаковки в формат PE, на основе него и стоит приводить данные. Ну собственно полученное выше можно прокомментировать примерно так: при добавлении св-ва Delimiter размер всех схем использующих StrCat возрастет, а размер схем, использующих StrCat+Delimiter вместо FormatStr уменьшится.