FYI, it does show in my version on gmail and on the mailman version.
BTW, I think strings do showcase some problems with this idea, .EQ. (as defined by Steven) is not recursive, which I think will be unworkable/unhelpful:
((0, 1), (1, 2)) and ([0, 1], [1, 2]) are not equal under the new operator (or new behaviour of == depending as per the OP) which I think goes completely against the idea in my book.
If it were (replace x==y with x == y || x .EQ. y with appropriate error handling), strings would not work as expected (I would say), e.g.:
[["f"], "o", "o"] .EQ. "foo"
because a an element of a string is also a string. Worse though, I guess any equal length string that are not equal:
"foo" .EQ. "bar"
would crash as it would keep recursing (i.e. string would have to be special cased).
What I do sometimes use/want (more often for casual coding/debugging, not real coding) is something that compares two objects created from JSON/can be made into JSON whether they are the same, sometimes wanting to ignore certain fields or tell you what the difference is. I do not think that could ever be an operator, but having a function that can help these kind of recursive comparisons would be great (I guess pytest uses/has such a function because it pretty nicely displays differences in sets, dictionaries and lists which are compared to each others in asserts).