Всё, что Ktor принимает на вход - функцию, которая конфигурирует Application.
Как организовать этот код - вопрос совершенно не связанный с Ktor'ом. Можно делать как угодно.
Можно хоть взять спринг, объявить интерфейс

interface KtorModule {
    fun Application.install()
}

накидать его реализаций с @Component и при запуске Ktor просто вызвать их в цикле

Это ещё нужно придумать, а решение не должно быть плохим или тяжело поддерживаемым.
Потому что в таком случае популяризация* ктора замедлится.

Вариант Harmonizr'а вполне неплох.
Не ожидал, что можно наследоваться в котлине так.
Это нужно добавить в официальный гайд.

Для роутинга, и интеграции с koin'ом это вполне хорошее решение.
Теперь могу со спокойной душой переписать всё на ктор.

Вот ведь сюрприз, при разработке ПО сложнее hello world нужно что-то придумывать.
Когда кода становится много, его конечно же нужно как-то структурировать. И одна из особенностей Ktor в том, что он не накладывает никаких ограничений вне своей зоны ответственности - работа с сетью.
Кому-то это не подходит, а надо готовые фреймворки, в которых нужно только вставить свой код в нужные места, а скелет уже готов.

Надо думать, но ты не можешь учесть всего.
Ты делаешь абстрактный вывод о том, что раз человек умеет в программирование, значит умеет всё.
Но ты не учитываешь, что например некоторые люди об этом не думают и просто плодят кучу extesion'ов
А потом каждый модуль описывают в конфиге или городят решение на рефлексии в перемешку с koin, который например вообще ушёл от двух стульев (кодогенерации и рефлексии) и спокойно работает и кому-то это может быть важно. А они вынуждены юзать рефлексию от незнания.
Или, что по предложению одного разраба решили всей командой перекатится на котлин и всех вещей не знают или не помнят.
Всё это создаёт барьер.

Есть языки, на которые все ругаются, а есть языки, на которых никто не пишет.
Последнее относится не только к языкам, а вообще ко всему.
И идеи ктора мне нравятся, но я сколько примеров не смотрел все поголовно писали спаггети код в одном модуле, это явно о чём-то, да говорит.

И всё, что я хочу сказать это:
Чёрт, да докиньте решение Harmonizr'а в доку и это решит 99% всех проблем.
Люди хотя бы поймут, что могут использовать привычный им стиль.

Для примеров обычно нормально быть куском спагетти.
И ещё: если поднимать сервер Ktor самому, а не через конфиг, лучше вообще забыть про такое понятие как модуль. Нет их, есть только Application и функции, которые с ним что-то делают.
Если поднимать через конфиг - то я понятия не имею, как с этим жить. Возможно, так вообще лучше не делать.
> привычный им стиль
Ну да, наследовать функциональные типы - это же привычно.

Я чёт не понимаю, зачем нужно моё решение. Можно же в обычную экстеншен-функцию передать параметры.

ну или так

Тем не менее рекомендуемый стиль по доке — модули

Осталось перевести это сообщение на английский и пойти пульнуть его в слаку, в #ktor. Там-то можно обсудить это дело с авторами и либо получить ответы, либо поговаривать их доку обновить :)

Хорошая идея, надо изучить вопрос.
Скорее всего будут разные решения.
Просто описать хотя бы 2-3 дополнительных с использованием разных видов di было бы классно.
Тем более по примерам учишься быстрее

В доке рассмотрен hello world.
Но наверное и в более сложном проекте с этим можно жить, если "модули" совершенно независимы и у них нет общих зависимостей.

Там так же есть примеры приложений.

Где?

плюс ещё на гитхабе можно поискать
В большинстве просто модули юзают
Кто-то, конечно, без конфиг файла

Да, действительно.
И пример как структурировать код тоже есть
https://ktor.io/samples/app/youkube.html

Видел, но тоже через модули
Или ты про Locations?
А вижу, есть функции расширения к роутингу

Там ровно один "модуль", а логика размазана по разным функциям внутри routing

И общие ресурсы передаются в эти функции аргументами