т.е. вопрос такой, есть ли способ модицифировать блок после его компиляции, или изменить порядок компиляции выполнения блоков

так используй флаги типа nocache

м.... можно подробнее, где их использовать и как это поможет?

просто при изменении данных на бэке — шаблон перерисовывается автоматически, если не установлен cache шалонизатора. Штука удобная на проде. Но можно вырезать куски для принудительного перерисовывания установим в блок\цикл пармер nocache (либо cache=false) точно не помню (см оф доки)

а поменять местами компиляцию шаблонов — это в корне нарушает интерпретацию PHP. Тк PHP реализует строчку за строчкой (если в упрощенном варианте)

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

не нарушает, Twig на выходе отдает строку, которая в дальнейшем исполняется при отрисовки страницы, мне по сути нужно поместить код с регистрацией статики в начало этой строки

Так тут варинтов не немного .. Нужно собрать статистику и сложить к примеру в cookie... и перед редорингом чекать есть там что то или запросить

в зависимость от детализации статистики можно чекнуть на контроллере \ на фронте при первом заходе

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

я не понимаю данного кейса, если честно... Если вам нужно что то персонализировать на UI, юзайте cookie, если нужно что то собрать и потом скинуть на обработку.. Самый простой и наиболее эффективный вариант APCu. Но при чем тут шаблонизатор... я не понимаю.. Задача шаблонизатора принять инфу с бэка и отрисовать HTML — "мозгов" должно быть минимум

мне кажется, вы все еще не поняли суть проблемы:)
ну вот пример допустим, у меня есть некая кастомная форма с каким то кастомным UI элементом, для его работы не нужны скрипты и стили.
у меня есть следующие варианты подключить эту статику:
- записать все это в app.js и app.css глобальную статику которая подключается везде - минусы очевидны: грузим много лишнего независимо от того нужно о для конечной страницы или нет (а код некоторых UI элементов может быть весьма объемный)
- в шаблоне контролера из которого вызывается форма заранее подключить скрипты и стили - минусы: приходится следить за тем где подключаются какие UI элементы, и контролировать наличие/отсутствие статики в соответствующих контролерах
- в шаблоне UI элемента помещать эту статику в блоки <link> и <script> - минусы: блоки link и script будут раскиданы по всему html страницы, будут многократно подключатся стили и скрипты. Да я понимаю что браузер все это съест и корректно обработает и по факту дважды с сервера ничего грузиться не будет, но некрасиво.
Что я хочу реализовать: в шаблоне UI элемента дергать twig функцию или тег, которая будет помешать факт подключения статики в какой-нибудь массив. Далее перед отправкой html клиенту, пробегать массив и подключать стили и скрипты туда где им место.

т.е. в идеале мне нужно обработать полученную с twig строку просто

видимо я вам точно уже не помогу..  с таким кейсом я вспомнил нашего devops у которого есть правило 3-х "нахуя"))) вот если смогут ответить.. значит надо подумать.. ))))

просто первый вопрос.. почему сразу не поместить в JS и не парится? вес JS библиотеки макс 500-700kb

ну тут скорее акодемический интерес чем практическая польза

ну а где интересы формата: асхирнности PHP (с промисами), балансировка фронта .. в этом направлении ... и интересно и полезно))

Для реализации вашей хотелки в Twig должен быть препроцессор/несколько проходов.
Потому что к моменту вызова вашей функции рендеринг head уже завершён.
Вы можете реализовать кастомный загрузчик с функцией препроцессора, но тут мой вопрос совпадает с вопросом Виктора: нахуя?

ну, когда мне нужен асинхронный пхп, я пишу на golang:) А вообще для асинхронного пхп вроде есть решения уже давно, не ковырялся. Просто имею опят работы на проекте с гиганской библиотекой статики, и полным трешем в плане ее подключения. Когда мне пришла задача "переместить всю статику туда где ей место" меня прошиб холодный пот. Благо тогда мы работали на smarty где пре/пост процесинг реализованы, и все решилось довольно быстро (как раз описанным выше решением). Сейчас работаю на другом стеке, и вроде надобности покамест нет. Но запилить реализацию под новый стек "для себя" все таки хочется (на практике такая система оказалась очень удобной)

И ребят, я все понимаю, но очень сложно не раздражатся на ответы "а нахуя", и "не недай так, просто сделай так вот". Говорю, интерес академический, решение хочется именно такое.