Ну так если пользователь укажет свою версию, конфликт разрешится по общим правилам

Ну вот это далеко не всегда происходит.

Я думаю, у вас проблема с подпроектами. Котлин не любит быть разных версий в разных модулях.

Но это
1. Закидон конкретного плагина
2. Решается использованием везде одной версии

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

Видимо у меня был косяк. Сейчас попробовал оверрайд версий работает

override не работает в случае, когда «котлин плагин инициализируется первым.

Например, в root проекте указываем kotlin(«jvm») version «1.4.32»

А потом в каком-нибудь внутреннем указываем kotlin(«jvm») version «1.5.10»
И когда начнёт обрабатываться это 1.5.10, то будет уже поздно. 1.4.32 уже добавили в classpath и провернуть фарш назад уже нельзя

Аналогично, и с каким-нибудь кастомным плагином, который тянет kotlin через implementation.
Если кастомный применяется рано-рано (как, например, Владимир советовал в settings), то всё будет норм.
Если же применится сначала какая-то версияя kotlin, а потом будет загружаться кастомный, то трындец. Хоть и указана там версия implementation(kotlin…), но уже поздно.

Ну в общем, оно заработало как надо и я тут же обнаружил баг в котлин 1.5.20-RC, правда не я первый.

Так всегда. Делаешь что-то для себя, натыкаешься на баг в Gradle, который оказывается багом в Kotlin, который оказывается ..

А куда почитать про плагины для сеттингов? У меня, наверное, гугл сломался.

Не, я просто эту штуку использую как раз для того, чтобы тестировать на разных новых версиях котлина. Специально для этого сделана переключаемая версия была

Ну, деалаешь my-cool.settings.gradle.kts, и потом подключаешь его к settings.gradle.kts через plugins {...}

Да не, я помню, что у Plugin есть дженерик параметр, просто интересно, что с их помощью делают.

По сути плагин — это кусочек build файла.

обычный плагин — кусочек build.gradle.kts.
settings плагин — кусочек settings.gradle.kts
init script плагин — кусочек init.settings.kts
и так далее

В settings, например:
pluginManagement — блок для указания верий плагинов (не подключение, а указание какие брать если что)
include(…) — т.е. settings плагин может понадобавлять include(..) на основе фазы луны или параметра или ещё чего (например, чтобы не поддтягивать всё-всё-всё в IDEA, а загружать только нужные модули)
includeBuild(…) — аналогично

Который оказывается багом jvm, который оказывается багом glibc?

Всё ещё плохо себе представляю юзкейсы -- это ж по сути одноразовая штука, если только тонны однотипных проектов нет под рукой, где такой плагин пригодился бы. Но буду иметь ввиду, спасибо!

https://github.com/jmfayard/refreshVersions — типичный settings плагин

У меня кто-то был плагин для сеттингз, который читал конфигурацию, скачивал из гита модули и генерил под них проекты