Kotlin version mismatch possible when using bindings from server

Context

Kotlin compiler's version used by the bindings server is regularly updated, and generally tracks the newest one. Also, the bindings server is the default, recommended way of consuming action bindings.

Problem

If someone uses a Kotlin version that is not compatible with the one that the bindings server used to compile the bindings, the compiler complains:

error: module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 2.1.0, expected version is 1.8.0. (main.kotlin_module)
error: incompatible classes were found in dependencies. Remove them from the classpath or use '-Xskip-metadata-version-check' to suppress errors
.github/workflows/branches-and-prs.main.kts:24:59: error: class 'io.github.typesafegithub.workflows.actions.actions.Checkout' was compiled with an incompatible version of Kotlin. The actual metadata version is 2.1.0, but the compiler version 1.8.0 can read versions up to 1.9.0.
The class is loaded from /Users/piotr/.m2/repository/actions/checkout/v4/checkout-v4.jar!/io/github/typesafegithub/workflows/actions/actions/Checkout.class
import io.github.typesafegithub.workflows.actions.actions.Checkout
                                                          ^

Ideas

• use the newest Kotlin version on the server, but tell it to produce output with fixed metadata (possibly to support a few years in the past?)
  • not sure if Kotlin gives us such an option
• expose multiple artifacts/versions/server routes, to give the user the control of the version of Kotlin the bindings are compiled with
  • this can easily get unbearably complex, TBD

Start by examining the bindings server's Kotlin compiler configuration and the generated artifact or versioning path. Compare the server's Kotlin metadata with consumer compiler versions and evaluate the proposed fixed-metadata or multiple-artifact approaches. Done means a concrete compatibility approach is selected with its supported versions defined.