I am not really the person (I don't know how Python is implemented) to explain how the correct behaviour should be achieved (sorry). I do appreciate that this may seem like exceptional behaviour. Numbers are a bit different.
However, for what its worth, I think that the 'correct behaviour' was implemented for subclasses of float and was working in Python 2.6, but not now in 2.7. I don't know how the earlier implementation was done, but it does work (I have used it to develop a nice little math library). Would there be any documentation about the implementation?
I would say that the semantics do not need to apply to arbitrary Python objects. The problem arises for numeric type subclasses when they are mixed with non-subclassed numeric types.
In that case:
For 'x opn y' any binary operator (like +,*, etc), if (and only if) 'x' is a built-in numeric type (int, long, float, complex) and 'y' is a subclass of a built-in numeric type, then y.__ropn__(x) (if it exists) should be called before x.__opn__(y).
If that were done, then subclasses of number types can implement commutative operator properties. Otherwise, I don't think it works properly.
I see this as 'special' behaviour required of the int, long, float and complex classes, rather than special behaviour for all Python objects.
If both 'x' and 'y' are subclasses of built in number types the required behaviour seems too complicated to specify. I would be inclined to do nothing special. That is, if both 'x' and 'y' are derived from built in numeric classes (possibly different types) then x.__opn__(y) would be called.
And should this apply to non-number types? I think not. Numbers deserve special treatment.
I hope this helps.