C++20 Modules: GCC 13 BMIs Rejected After Toolchain Upgrade to GCC 14

Module builds break at the compiler boundary

A project uses named C++20 modules and compiles cleanly on developer machines running GCC 13. After the production toolchain moves to GCC 14, importing those same modules fails with BMI version mismatch errors, even though no source code changed.

From what I understand, the C++ standard deliberately leaves the Binary Module Interface format unspecified, so BMIs are compiler-specific build artifacts rather than portable outputs. That raises a design question for projects that want to cache or distribute compiled modules across environments.

Constraints

• Developer machines and CI/production runners may not always share identical compiler versions, including patch level.
• Some translation units still use traditional headers, so modules and non-module code are mixed in one binary.
• Prebuilt BMIs would speed up CI, but only if they remain valid across environments.

Open questions

1. Is exact compiler version parity (down to patch release) a hard requirement for any project distributing or caching BMIs, or are there documented cases of cross-version compatibility?
2. Do header units (import <vector>;) actually reduce this fragility, or do they carry the same version-locking constraints as named modules?
3. Is shipping headers instead of precompiled modules the only portable option for libraries consumed by external projects?