And there also exist expressions for the left-hand side that make both expressions truthy, like [0]:

  $v = $null, $null, 1

  ($v -eq $null) -and ($v -ne $null) # True

In both these cases, this is caused by the language having built-in binary operators for when the left-hand side expression is a collection type that perform the operation elementwise and return an array.

Interestingly, it seems like PowerShell's operator overload resolution in general depends entirely on the type of the LHS. I say 'seems' because I couldn't find any sort of language specification when I looked into it a while ago like what C# and VB.NET have, and testing seemed to confirm that this was the case. Now, searching the PowerShell Core source, it seems from [1] that this is indeed the implementation.

This contrasts with C# [2] and VB.NET [3], where binary operator overload resolution is treated as if the candidate operator implementations were a two-parameter method group, making the resolution process 'commutative' (though not always commutative in practice as the operators themselves can still have different LHS and RHS types {Edit: example from the CLR [4]: +(Point, Size) but not +(Size, Point)}).

[0] https://blog.iisreset.me/schrodingers-argumentlist/

[1] https://github.com/PowerShell/PowerShell/blob/master/src/Sys...

[2] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

[3] https://docs.microsoft.com/en-us/dotnet/visual-basic/referen...

[4] https://source.dot.net/#System.Drawing.Primitives/System/Dra...