Even more unrelated, but equally pedantic, I've always thought it's weird when people write "null != val" instead of "val != null" for the same reason.
When said out loud, "null is not val" just feels wrong.
I find initializing condtions like `if(Type variable = ...)` to be very nice in C++ to avoid excessive nesting while still keeping the variable scoped to the block. Of course, I also enable -Wparentheses for things like `if(val=null)`, which you get e.g. when using -Wall with both GCC and Clang.
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)}).
When said out loud, "null is not val" just feels wrong.