Currently desired bytecode version is clamped to the maximum. This allows requesting bytecode versions that do not exist. We have added callsite validation for this in StableHLO to ensure we don't pass an invalid version number, probably better if this is managed upstream. If a user wants to use the current version, then omitting setDesiredBytecodeVersion is the best way to do that (as opposed to providing a large number).
Adding this check will also properly error on older version numbers as we increment the minimum supported version. Silently claming on minimum version would likely lead to unintentional forward incompatibilities.
Separately, due to bytecode version being int64_t and using methods to read/write uints, we can generate payloads with invalid version numbers:
mlir-opt file.mlir --emit-bytecode --emit-bytecode-version=-1 | mlir-opt <stdin>:0:0: error: bytecode version 18446744073709551615 is newer than the current version 5
This is fixed with version bounds checking as well.