elm.lock versus a pinned Docker image for enforcing identical Elm compiler versions

In Elm 0.19.x, projects can achieve reproducible package resolution through elm.lock, which records exact package versions and revision hashes. However, the lock file does not pin the Elm compiler binary itself, so two machines with different installed compiler versions may still produce divergent build artifacts or error messages.

One documented approach is to standardize on a native installation procedure and document the required compiler version in the project README, relying on elm.lock for dependency determinism. The alternative is to require a fixed Docker image, such as elmlang/elm:0.19.1-slim, so that the compiler, runtime, and package tooling are identical across environments. The trade-off involves container maintenance overhead and the possibility that host system libraries affect native module compilation inside the container.

When the primary constraint is identical compiler behavior rather than dependency resolution, which approach better balances reproducibility with contributor friction?

1. Does elm.lock provide any mechanism to detect or reject a mismatch between the running compiler version and the version used to generate the lock file?
2. If a team adopts a pinned Docker image, how can they verify that host-level dependencies are not altering the build environment in ways that break reproducibility?
3. For projects without native modules, is a documented native compiler version sufficient to match the determinism of a containerized toolchain?