Но обычно популярные библиотеки пристально следят за этим

И если не ломать. В вебе особенно заметно, потому что забивали на это

Только в бекенде вероятно пофиг

А в чём зло тогда?

А главное, как жить?

чёт да, я тоже не понял, что теперь делать

В вебе проблема не в транзитивных зависимостях, а в убитой сборке.

Затаскивать в библиотеки только те зависимости, которые реально нужны?

ну это слишком очевидно

А как в целом быть, если у меня в библиотеке - okhttp будет одной версии, а в приложениях, которые будут его использовать - может быть более старая, или более новая? Вопрос даже не конкретно про OkHttp, а и про любую другую зависимость.

Конфликт версий решает система сборки. Gradle по дефолту берёт самую новую.

То есть, в теории, если между версиями библиотек плохая совместимость, в плане того же api, то будет падение в рантайме? Или ошибка компиляции? Например моя библиотека MyLibrary зависит от OtherLibrary. И вызывает у OtherLibrary метод, который в более новой версии библиотеки, например, убрали или поменяли сигнатуру.
Я к тому, если у пользователя будет более новая версия библиотеки, то Gradle и моей либе её подставит?

И как и что произойдёт?)

Если из вашей библиотеки зависимость торчит в API (и объявлена соответственно), то может взорваться во время компиляции.
Если у зависимости сломана совместимость ABI, может взорваться в рантайме.

Скорее всего NoSuchMethodError или что-то в этом роде

В общем, кровь-кишки-крэши

val analysisResult - JvmResolveUtil.analyze(...)
val kotlinType = ktParameter.getAbbreviatedTypeOrType(analysisResult.bindingContext)
val source = kotlinType.typeConstructor.source
val psi = source.psi

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

в InteliJ очень не хватает функции "покажи все экстеншны к классу"

потому что вся самая мякотка как раз в них

Find usages
> Extension receiver type