Make -is [pscustomobject] and -as [pscustomobject] work meaningfully

[mklement0]

Note: The following discusses the issue with respect to the -is operator, but the same applies to the
-as operator (which is currently broken even when using the full type name - see #4343).

-is [pscustomobject] (and analogously -as [pscustomobject]) should work meaningfully as follows:

# -is [pscustomobject] should only be true for true 
# [System.Management.Automation.PSCustomObject] instances
# (PSObject instances without a .NET base object)

[pscustomobject] @{} -is [pscustomobject] | Should -BeTrue # OK
42 -is [pscustomobject] | Should -BeFalse  # OK
(Get-Item /) -is [pscustomobject] | Should -BeFalse  # BROKEN
(Write-Output 42) -is [pscustomobject] | Should -BeFalse # BROKEN

---

Background Information

Currently, the only way to test meaningfully for whether a given value is a custom object is to do the use the full type name:

# Works, but only with the *full* type name.
[pscustomobject] @{} -is [System.Management.Automation.PSCustomObject] | Should -BeTrue
(Get-Item /) -is [System.Management.Automation.PSCustomObject] | Should -BeFalse

Surprisingly, [pscustomobject] does not work meaningfully:

# !! Returns $true, because [pscustomobject] is really [psobject]
(Get-Item /) -is [pscustomobject] 

The reason is that [pscustomobject] is unexpectedly the same as [psobject] (!), i.e., it is type accelerator for System.Management.Automation.PSObject rather than for System.Management.Automation.PSCustomObject, for historical reasons (see #4344).
Therefore, any [psobject]-wrapped .NET object returns $true for -is [pscustomobject], which is both confusing and virtually useless.

Note that there already is precedent for situationally distinguishing between [pscustomobject] and [psobject], namely in the context of custom-object literals via syntactic sugar [pscustomobject] @{ ... } (constructs a custom object), which doesn't work with [psobject] @{ ... } (constructs a hashtable and uselessly wraps it in [psobject]).

See also:

• AutomationNull Behaviour #9997, where meaningful use of -is [AutomationNull] is proposed to allow distinguishing [System.Management.Automation.Internal.AutomationNull]::Value values from true $null values.

• Pending PR Add -is $null and -isnot $null support to operators and Where-Object #10704, which implements the ability to use-is $null to test for $null values.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.