Note: The repro below uses the ValidateSet attribute to demonstrate the problem, but at least one other attribute is affected too, namely ValidatePattern - possibly more. Presumably, fixing the problem for one attribute also fixes it for the others.

Update:

• The core issue is that when script block text with parameter declarations is invoked via Invoke-Expression, default-parameter-value validation for parameters that have Validate* attributes takes place in an overzealous manner: even if there is no default value, the implied value of $null is evaluated against the validation attributes - however, it should be possible to simply omit a default value for validation-constrained parameters (and that is how it works with direct invocations of functions / scripts / script-block literals).

  • @SeeminglyScience's comment below provides helpful analysis of the root cause, source-code links, and a suggested fix.

• As an aside: The helpful aspect of this validation - namely if there is a default value - is currently missing from direct function / script / script-block literal invocations; remedying that is the subject of For validation-constrained function parameters, prevent invalid default values. #8795.

Steps to reproduce

. { param([ValidateSet("one", "two")] $foo) "hi" }
# This command should be equivalent to the above.
Invoke-Expression 'param([ValidateSet("one", "two")] $foo) "hi"'

Expected behavior

hi
hi

Actual behavior

hi
Invoke-Expression : The attribute cannot be added because variable foo with value  would no longer be valid.

PowerShell Core v6.2.0-preview.3 on macOS 10.14.2
PowerShell Core v6.2.0-preview.3 on Ubuntu 18.04.1 LTS
PowerShell Core v6.2.0-preview.3 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)