Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Note: Initializing via [hashtable] used to break too, but that was fixed in #19402 / #19415.

In an array-type-constrained variable (as in expressions in general), AutomationNull is treated like $null; e.g.:

# Note: & { } is a simple way to return the AutomationNull singleton.
# OK: no error
[string[]] $arr = & { }

By contrast, using AutomationNull in [pscustomobject]-based object initializers fails:

class Example {
   [string[]]$LogMessage
}

$automationNull = & {}

# !! BREAKS: ""Type 'System.String[]' does not have a default constructor (Parameter 'type')""
[Example] [pscustomobject] @{ 'LogMessage' = $automationNull }

The symptom is reminiscent of #19384 (comment)

Expected behavior

An [Example] instance should be constructed, with $null returned from its .LogMessage property.

Note: If this is resolved in the same way as for hashtable initializers, it is actually [System.Management.Automation.Internal.AutomationNull]::Value that is stored in the property, but on accessing (getting) it, it turns to $null.

Outside of a class this behavior is directly visible:

# -> $true
 [object]::ReferenceEquals((
  [string[]] $arr = & { }), 
  [System.Management.Automation.Internal.AutomationNull]::Value
)

Actual behavior

InvalidArgument: 
Cannot convert value "@{LogMessage=}" to type "Example". 
Error: "Type 'System.String[]' does not have a default constructor (Parameter 'type')"

Error details

No response

Environment data

PowerShell Core 7.4.0-preview.3

Visuals

No response