Windows PowerShell 5.1 and PowerShell 7: Which Export-Csv Encoding Contract Keeps a Cross-Platform Dev Environment Reproducible?

The goal is a repeatable development environment: one set of CSV-export scripts that runs unchanged under Windows PowerShell 5.1 and PowerShell 7.x, on both Windows and Linux agents, producing artifacts that downstream consumers decode identically on every run.

The friction point is Export-Csv's default encoding. Windows PowerShell 5.1 writes UTF-16LE with a BOM; PowerShell 7 defaults to UTF-8 without a BOM. Both editions accept an explicit -Encoding parameter, but the default is not documented as a stable contract, so pipelines that rely on it implicitly can drift between editions or future releases. BOM-sensitive consumers — spreadsheet imports, diff tooling, third-party parsers — make the choice consequential rather than cosmetic. The exact defaults for the targeted 7.x release should be re-confirmed against current documentation before standardizing.

Three open decisions follow:

• Should every shared Export-Csv call declare -Encoding explicitly, and is UTF-8 with or without a BOM the safer contract for mixed consumers?
• What lightweight CI check can detect a silent default-encoding change without brittle byte-level assertions?
• Does containerized Linux execution add locale- or filesystem-dependent BOM variability that a pinned encoding would not already cover?