Conda environment.yml exports lack explicit build-string pinning for cross-platform reproducibility

Context

Conda environments are exported to environment.yml files to enable reproduction across machines. The export includes package names, versions, and channel sources, but omits the build-string identifiers (e.g., py39h123456_1) that encode compiler toolchain, ABI flags, and optional feature toggles.

Goal

Determine whether a portable export should embed full build strings to guarantee bit-for-bit identical environments on Linux, macOS, and Windows, or whether the current version-only specification is sufficient for functional equivalence.

Constraints and uncertainty

Build strings are platform-specific; pinning them in a shared YAML file would break cross-OS installs unless conditional logic or multiple lock files are introduced. Conda’s solver can usually satisfy version constraints with compatible builds, yet subtle behavioral differences (SIMD optimizations, BLAS backend selection, feature flags) have been observed when the same version resolves to different builds.

Questions

1. Does Conda provide a documented strategy for achieving build-level reproducibility across heterogeneous platforms without maintaining per-platform lock files?
2. Are there solver flags or configuration options that enforce strict build-string matching during conda env create when the export omits them?
3. What is the recommended workflow for teams that require identical binary artifacts on CI runners and developer workstations running different operating systems?