See the comments in #9794 for the full extent of the existing discussion, starting with #9794 (comment)

AutomationNull.Value is sometimes detectable and distinguishable from $null in certain cases, for example:

using namespace System.Management.Automation.Internal

$null -is [psobject] # false
[AutomationNull]::Value -is [psobject] # true

@($null).Count # 1
@([AutomationNull]::Value).Count # 0

@SeeminglyScience mentioned a possible way we could have it be handled more closely like [dbnull] and [nullstring] are being handled as of #9794, without losing its current function in the pipeline internals, in #9794 (comment):

Ideally if this were to be fixed it would just be removed from assignment, e.g. $obj = [AutomationNull]::Value would populate $obj with true null. The -is operator is one of the few things that never "lie" on occasion and I think it would be a detriment to change that.

You can also make [AutomationNull]::Value -is [AutomationNull] work by:

1. Removing the static keyword from the class decl
2. Make it inherit PSObject
3. Change the singleton instance to new AutomationNull()

That would allow $autoNull -is [psobject] to still work while enabling $autoNull -is [AutomationNull]. Though I think there are a few places in the compiler where it uses a pattern like if (expr.ExpressionType == typeof(PSObject) && expr.Value == AutomationNull.Value) so that might need to change.

/cc @daxian-dbw @mklement0

I'm personally in favor of Patrick's solution, as it enables the very clear and concise $item -is [AutomationNull] with few downsides (the biggest downside being potential implementation complications, but in my opinion these are probably worth tackling). Interested to hear any further discussion on this! 💖