Насколько я помню, у вас в итоге получается приложение - тот же мэйн. Дальше окошками и прочим вы уже управляете через создания инстансов

Там есть рефлективные решения в DI, но этим можно не пользоваться

Ну так в том и дело

tornadofx-open-new-window-demo/Hello.kt at master · freewind-demos/tornadofx-open-new-window-demo
https://github.com/freewind-demos/tornadofx-open-new-window-demo/blob/master/src/main/kotlin/example/Hello.kt

Одна из первых ссылок в гугле, где там рефлексия-то?

Более того, если чуть копнуть - можно вообще (почти) без ::класс всё делать

Он имеет в виду что типа потом под капотом вызывается .createNewInstance() для KClass объектов которые в конструктор App передает

Там можно это руками сделать через оверрайт старта в App/

Т. к. в джаву очень поздно завезли функциональщину, задачи, которые прямо решаются лямбдами и ФВП (то же кэширование и транзакции), стали решать аннотациями, ползанием рефлексией и байткод-процессингом.
При этом потерялась ссылочная прозрачность. Если у меня есть метод inTransaction(block: () -> T): T - я могу провалиться в его исходники и посмотреть, что он делает. Если у меня есть только @Transactional на методе - мне ещё надо кучу времени потратить, чтобы найти, кто эту аннотацию процессит. И там будет не прямо готовый код, а кодогенератор.

Да при чем тут функциональщина вообще? Что такое функциональщина?

Ну я же привёл пример с @Transactional и inTransaction(block: () -> T): T

При чем тут UI?

Я не понял, к чему вы про это кодогенерацию вообще

выключаем ФП головного мозга :)

Чтобы оно получилось, мне надо СРАЗУ дать ему имя класса главного окна.
А в моём кейсе окна могли создаваться не на старте, и их могло быть несколько.

Оверрайдите стартовый метод и делаете что угодно

Я отвечал на вопрос, что из опыта со спрингом породило аллергию на рефлексию

Не что, а какой опыт. Сколько времени вы с ним работали?

Года... три точно, наверно больше

Ну ладно, а то я думал, что "не читал, но осуждаю".