Array subexpression @($list) throws "Argument types do not match" for List[object] created by New-Object #27558

Summary

The array-subexpression operator itself throws System.ArgumentException: Argument types do not match when it wraps a System.Collections.Generic.List[object] created by New-Object.

UI Automation, ConvertTo-Json, and the original $pair[1] access are not required. They only made the issue visible in the original application.

Minimal reproduction

$list = New-Object System.Collections.Generic.List[object]
@($list)

The list can be empty.

Actual output

OperationStopped: Argument types do not match

Expected output

@($list) should not throw and should behave consistently with the same public .NET type created with its constructor. In the tested environment, the constructor-created empty list produces an empty object[]:

$list = [System.Collections.Generic.List[object]]::new()
@($list) # succeeds

Comparison

function Test-Case($name, [scriptblock]$body) {
    try {
        & $body | Out-Null
        $name + ': OK'
    }
    catch {
        $name + ': FAIL - ' + $_.Exception.Message
    }
}

$newObjectList = New-Object System.Collections.Generic.List[object]
$constructorList = [System.Collections.Generic.List[object]]::new()

Test-Case 'New-Object + @()' { @($newObjectList) }
Test-Case 'constructor + @()' { @($constructorList) }
Test-Case 'New-Object + [array]' { [array]$newObjectList }
Test-Case 'New-Object + ToArray' { $newObjectList.ToArray() }

Observed:

New-Object + @(): FAIL - Argument types do not match
constructor + @(): OK
New-Object + [array]: OK
New-Object + ToArray: OK

Both values report the same public types:

GetType():                         System.Collections.Generic.List[System.Object]
PSObject.BaseObject type:          System.Collections.Generic.List[System.Object]
PSObject.ImmediateBaseObject type: System.Collections.Generic.List[System.Object]

The failure is specific in the tested matrix:

Stack trace

The exception occurs while evaluating @($list), before any JSON serialization. The top stack frames are:

at System.Linq.Expressions.Expression.Condition(...)
at System.Management.Automation.Language.PSEnumerableBinder.MaybeDebase(...)
at System.Management.Automation.Language.PSToObjectArrayBinder.Bind(...)

Workarounds

$list = [System.Collections.Generic.List[object]]::new()
[array]$list
$list.ToArray()

In the original application, removing the unnecessary array-subexpression also avoids the failure:

- controls = @($pair[1])
+ controls = $pair[1]

Environment

Reproduced on:

• PowerShell 7.6.3 on Windows 11 10.0.26200
• Windows PowerShell 5.1.26100.8655 on the same machine

The original report attributed the failure to UI Automation-derived hashtables and ConvertTo-Json. Further reduction after reviewer feedback shows that neither is required.

Related issues

• PowerShell #5579: implicit PSObject wrapping and serialization behavior
• PowerShell #4280 and PR #4296: earlier work on array-subexpression behavior and List[object]