In many contexts PowerShell uses the invariant culture for string operations for predictable operation irrespective of the session's current culture.

For instance, "$(1.2)" (string interpolation in expandable strings) yields '1.2' even in cultures that use ,, not . as the decimal mark, and cast to numeric types (e.g., [double] '1.2') are similarly culture-invariant.

The -split and -replace operators implicitly convert their LHS operands to strings, if they aren't, but while -split commendable uses the culture-invariant conversion (as in expandable strings),
-replace is unexpectedly culture-sensitive

Steps to reproduce

Describe "Culture-invariance tests for -split and -replace" {
  BeforeAll {
      $prevCulture = [cultureinfo]::CurrentCulture
      [cultureinfo]::CurrentCulture = 'fr' # The French culture uses "," as the decimal mark.
  }
  It "-skip: LHS stringification is not culture-sensitive" {
    1.2 -split ',' | Should -Be '1.2'
  }
  It "-replace: LHS stringification is not culture-sensitive" {
    1.2 -replace ',' | Should -Be '1.2'
  }
  AfterAll {
      [cultureinfo]::CurrentCulture = $prevCulture
  }
}

Expected behavior

The tests should pass.

Actual behavior

The -replace test fails:

      Expected: '1.2'
      But was:  '12'

That is, 1.2 was unexpectedly stringified culture-sensitively, as '1,2'.

Environment data

PowerShell Core 7.0.0-preview.5