This question was originally (and reasonably) closed as a duplicate of the following questions:

• Why is an empty PowerShell pipeline not the same as null?
• Why is piping null to set-variable causing different outcomes?

However @mklement0 and others provide a lot of details in comments in this question which deserve to be captured in a more visible and collected answer, though they may be repeated somewhat in mklement0's answers to the other questions. As I (OP) am the learner in this situation, feel free to edit the answer/provide corrections.

The core of this question (and the linked duplicates) revolves around the technical differences between $null and "automation null" ([System.Management.Automation.Internal.AutomationNull]::Value), a.k.a. "the enumerable null".

To answer the direct questions in the OP:

• What is the difference between $a and $c in this situation?

  • $a is $null, while $c is automation null. Automation null is returned via a pipeline that has no results, which can be achieved in different ways, as demonstrated by the different questions:
    • Get-Process | Where-Object { $_.Name -eq "oiawmij3209j23oifnoeicn" }
    • 1,2,3,4 | ? { $_ -ge 5 }
    • & { }

• Why does $c.PSObject.Copy() work when $a.PSObject.Copy() doesn't?

  • Because $c, as automation null is technically a [PSObject] with a PSObject property, while $a is just $null.
  • However the fact that $c.PSObject can be accessed is arguably a bug, see further context below.

• Why does $c.PSObject.Copy() work when $c.GetType() doesn't?

  • In the former context you are simply accessing an existing property of $c.
  • The latter context is an expression, where $c is effectively being evaluated to $null, and is thus equivalent to $null.GetType().

• What causes this? Is it something to do with Where-Object, or to do with PSObject.Copy(), or something else?

  • As noted, automation null is being returned by the pipeline where Where-Object returns no results.

• How can I/should I reliably differentiate between/test for these cases?

  • In the current implementation, automation null is exposed as a [PSObject], and so detecting it, and differentiating it from $null can be achieved with ($null -eq $value) -and ($value -is [PSObject]).
  • Alternatively, you can probe the enumerability like so: ($null -eq $value) -and (@($value).length -eq 0), or ($null -eq $value) -and (@($value).count -eq 0).
    • The length/count of an array containing automation null will be 0, while that of @($null) will be 1 (for reasons someone more experienced would have to explain).
  • However see below about potential future improvements, which would presumably break one or both of these detection methods.

Further context:

• Currently, automation null behaves as $null in expressions, but acts differently in enumeration contexts such as the pipeline, where it acts like an empty collection and therefore enumerates nothing.
• The fact that the enumerable null even surfaces as an object in PowerShell code (enabling things like (& {}).psobject and (& {}) -is [psobject] is arguably a bug; a leaky implementation of an abstraction which reveals the fact that it is technically an object (of type [psobject] a.k.a. [System.Management.Automation.PSObject], namely the aforementioned [System.Management.Automation.Internal.AutomationNull]::Value singleton).
• A green-lit enhancement that has yet to be implemented (as of PowerShell 7.5.0) will enable a conceptually appropriate test for whether a given value is the enumerable null: $value -is [System.Management.Automation.Null].
• As noted, see the duplicates linked above for more detail in mklement0's various answers.