The user should be able to specify a "target version" of Nextflow, either through client configuration or the manifest.nextflowVersion config option. Language features in the Nextflow codebase can then be annotated with a minimum version, so that if the user tries to use a feature with an older target version, the language server emits an error.

The same pattern can be followed for deprecating features, i.e. providing a deprecation warning and eventually an error when the feature is removed.

It could even be used to identify common mistakes or pitfalls with specific versions, although we should be careful not to add too much static analysis in the background and hurt performance.

Since the language server imports Nextflow as a library, I think the best approach would be for Nextflow itself to start having some level of backward compatibility, so that it can i.e. parse and understand deprecated features enough to emit an error. Then the language server can just use the latest version of Nextflow. I don't think we need to extend all the way back to DSL1, maybe just 23.10 or 22.10.

Since we are moving away from "DSL" as a way to describe Nextflow, we will simply use the Nextflow version to track both the language and the runtime.