Well, "==" whould allow the wanted feature by exception through meta classes for concerned classes:

>>> class X:
... 	a=1
... 
>>> Y=X
>>> class X:
... 	a=1
... 
>>> Y==X
False
>>> class XCompare(type):
... 	def __eq__(self, other):
... 		print "tolerant class __eq__"
... 		return self.__name__ == other.__name__
... 
>>> class X:
... 	__metaclass__ = XCompare
... 	a=1
... 
>>> Y=X
>>> class X:
... 	a=1
... 
>>> Y==X
tolerant class __eq__
True
>>> 


Better than nothing. Its a improvement generally, independently.
But thinking about my acutal use cases and all: It still doesn't satisfy. I don't want to introduce this extra magic on all those classes just for that feature - because when needed, the majority of classes are concerned (see below). One can have only one meta class ... its too tricky and off-road to guess for most programmers ... 

"when in doubt, raise an error": That is IMHO too rigid here, and generally when a feature is then hindered too much. Aren't warnings the right tool for such case? If really rarely there is problem, should it surface easily already during dev & test time?
Compared to the everday life danger of Pythons dynamic attribute access, version incompatibilities, etc. its about a rather harmless issue here.

Now I'd vote for a warnings.warn upon "==" (or old "is") failing , and then an error only when the .__name__ is not matching too. A warning at dev & test time should be enough, when just "==" (or "is") fails. 


I mainly like the tolerance during development: e.g. fast reload style edit-run cycles (reload sometimes improved with special reload fix code), because I noticed that 95% of code changes/bug fixes do not require a full expensive app-restart. This pays off particularly with bigger GUI app development/fixing and similar, where lot of status is accumulated expensively during run time.
But I wished that feature already for a deployed app too.