Note: It may be too late to change this behavior, or it may fall into Bucket 3: Unlikely Grey Area.
If the former, the pitfall discussed is at least worth documenting.

about_Switch states about the syntax of individual switch branches:

 "string"|number|variable|{ expression } { statementlist }  

The above suggests that an expression can only be used inside script blocks, but in practice you can also use (...)- and $(...)-enclosed expressions directly (e.g., (1 + 2)) and even method calls (e.g., $PSVersionTable.PSVersion.ToString()).

Surprisingly, however, a non-numeric unquoted token that doesn't start with ( or $ (and doesn't break parsing) is unexpectedly treated like an (expandable) string rather than as an expression:

Steps to reproduce

0 -eq [uint32]::MinValue

switch (0) {
 ([uint32]::MinValue) { $true }  # OK - (...) ensures use as expression
 default { $false }
}

switch (0) {
 [uint32]::MinValue { $true }  # !! condition treated as *string*
 default { $false }
}

switch ('[uint32]::MinValue') {
 [uint32]::MinValue { $true }
 default { $false }
}

Expected behavior

True
True
True
False

Actual behavior

True
True
False
True

That is, unquoted [uint32]::MinValue is interpreted the same way as '[uint32]::MinValue' in this case.

This is unexpected, given that it is reasonable to conceive of the branch conditions of a switch statement as the RHS of an expression along the lines of <switch-value> -eq <branch-condition>, and given that any unquoted token on the RHS of -eq is interpreted as an expression.

Environment data

PowerShell Core v6.0.0-alpha (v6.0.0-alpha.18) on Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64