Eric's current proposal sounds sensible to me, but I'll note that if we deem it necessary, the code that implicitly sets `__hash__ = None` to override object.__hash__ when __eq__ is defined could also set some other marker to make it more explicit that that happened.

I think Eric's proposed heuristic will be sufficient, though - for subclasses that inherit both __hash__ and __eq__ from a base class the dataclass decorator won't pay any attention to either of them, and if a base class has set __hash__ to something, then the type creation machinery won't inject "__hash__ = None" into the class being defined.