Note: This isn't a bug per se, but a performance issue.

Note that -creplace and switch -regex -casesensitive appear NOT to be affected.

Steps to reproduce

$strArray = , 'foo' * 1e5  # an array with N elements containing 'foo'
# Contrast the performance of -match vs. -cmatch
$scriptBlocks = 
 { foreach ($str in $strArray) { $null = $str -match  'f?(o)' } },
 { foreach ($str in $strArray) { $null = $str -cmatch 'f?(o)' } }

$scriptBlocks | % { (Measure-Command $_).TotalSeconds }

Expected behavior

Roughly the same execution time in both cases - -cmatch should actually be slightly faster.

Actual behavior

Sample result from my macOS 10.14.3 machine:

0.6651756
1.3135713

That is, -cmatch unexpectedly took about twice as long.

That this may be related to unexpectedly bypassing .NET's automatic caching of on-demand-compiled regexes is evidenced by the fact that if you force caching as follows, the problem goes away:

# Forces caching of the regex; running the above code again then performs as expected.
$null = switch -casesensitive -regex ($null) { 'f?(o)' { } }

Environment data

PowerShell Core v6.2.0-preview.4 on macOS 10.14.2
PowerShell Core v6.2.0-preview.4 on Ubuntu 18.04.1 LTS
PowerShell Core v6.2.0-preview.4 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.471)
Windows PowerShell v5.1.17134.407 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.471)