> I'm going to ignore this issue until you two have reached agreement.
> I recommend using some example code.

That won't be necessary.  I now understand what the OP is trying to do and am going to recommend against it.  

Guido, this really a decision for you to make.  Formerly ABC logic existed independent of any other class logic.  Nothing else in the standard library or in third-party tooling was required to take it into account.  A developer could leave or take it if they pleased.

The OP is proposing much tighter coupling and interdependence.  Effectively, he wants two new general rules to apply pervasively to existing tooling that previously had no reason to interact with ABCs at all.

1) When checking to see if a method exists, perhaps by using hasattr(), it should exclude abstract methods as determined by a follow-up getattr() call.

2) If a tool dynamically adds a method, it has duty to call update_abstractmethods() if even a slim possibility exists that ABCs are being used.

Presumably, none of this is unique to the total_ordering() decorator and it would apply to anything that dynamically inspects or updates classes whether by direct call, by class decorator, or by metaclass.

My recommendation is to not go down this path.  In the particular case of total_ordering(), the value add is slightly above zero.  In the decade long history of ABCs and the total_ordering() decorator, the need for this has arisen zero times.

P.S.  In the standard library, only the numbers module has ABCs with abstract rich comparison methods.  Typically, these would be used by registering the ABC rather than by inheriting from it.  That may be one reason why this hasn't come up.