Hi Chris - well maybe we're looking at different questions. Your examples show it is possible to construct a data type where == None does not work. Clearly that is possible.
1. One conclusion is that the possibility of such == means that in general the == None form is unreliable. This is the proper mindset of the Python implementation, where the classes that need to work are practically unlimited, so relying on == would be unreliable as shown.
2. However, I am interested in the mass of ordinary looking programs that use strings, lists, ints, dicts, tuples, functions etc. to solve some problem. It's extremely likely that all of the classes in such a program have a reasonable definitions of ==. So if the programmer knows that, they can use the "== None" form in complete confidence. It works perfectly.
It's possible to treat (1) as kind definitive, like that possibility ends the argument. I agree (1) is true, but do not find it convincing about the (2) case. I think (2) is more useful for thinking about Python programs in the world.
Best,
Nick