@Girgias @preinheimer @IceWolf @cptwtf @ramsey @Crell

What doesn't make sense to me is that the operator would ever try to do type-conversion when it's comparing the same type on both sides, and where that type already has comparison rules (even for < and >).

Note that when the string-contents are not formatted as a number, all four operators just do what you'd expect (i.e. use string-comparison rules).

That means it must be first attempting to parse the string as a number, and only if that fails does it use string rules.

This seems wasteful of CPU, however trivially, in addition to the unexpected behavior.

...and given that this can cause false-positive matches specifically when looking at the output of a hash-function, I have to wonder if it doesn't also represent a security vulnerability.

Language opinions aside, the manual should at least clarify the point that all 4 operators will first try to compare two strings as numeric before falling back to what you'd expect -- and should probably note conditions under which two differing strings can be evaluated as equal (there are others, though probably more obvious/expected).