the main purpose of my-lib is to provide a list of curated compatible libraries for a particular environment. So I can use different versions of my-lib depending on OS, jvm version etc.

Yes, this is expected - apps always control the finally library selection

Thanks, Alex.

For clarity - it would be expected that the app's deps.edn would take precedence if iT said anything about some/dep. But in @U34K4458X's original case, the app's deps.edn said nothing about some/dep but rather got some/dep transitively via a lib that also got it transitively and tried to downgrade some/dep to 1.5.0. Is the use case of a lib providing a curated compatible set of libraries suported, or is it considered an antipattern because resolution of conflict at one level (the top) is simpler (for the rigorous definition of "simple") than at multiple levels (i.e., all intermediate libraries that have an opinion)?

libs never control what versions are present at the time of use - that is always ultimately a consequences of the specification at the top (app) level

lib dep versions should always be treated as nothing stronger than a suggestion :)

if you want to learn more about how dep expansion and version selection is done for deps.edn, see https://clojure.org/reference/dep_expansion