In Using CQL, the Mime Type version guidance says:

The version of CQL/ELM used for content in a library SHOULD be specified using the version parameter of the text/cql and application/elm+xml, application/elm+json media types.

text/cql; version=1.5

• application/elm+xml; version=1.5

• application/elm+json; version=1.5

If this guidance is followed, however, then the library will not conform to the CQL Library profile because that profile requires a content with contentType fixed to "text/cql" (without a version). Similarly, the ELMLibrary profile specifies content slices by fixing contentType to versionless contentTypes as well.

I don't think that a best practice should conflict w/ formal profiles – but I'm not sure the best way to move forward. The only thing I can think of is to create a code system and value set in THO for each mime type, with each one representing all the possible answers (the versionless mime type plus a versioned mime type for each release of CQL) - then in the profile, bind contentType to the appropriate mime type. The main drawback there, however, is that the code systems / value sets will need to be updated with each CQL release.