Mark,

Is this still of interest?

I found the relevant changes in py3k, but I am not sure it is the behavior that gumtree is expecting.  Since py3k removes coercion completely, the test case from issue 3734 would just issue:

   Traceback (most recent call last):
     File "test-5211.py", line 34, in <module>
       print type(z + xz)
     File "test-5211.py", line 5, in __coerce__
       t = complex.__coerce__(self,other)
   AttributeError: type object 'complex' has no attribute '__coerce__'

Where as I think gumtree wants the xcomplex case to behave as the xfloat case, e.g.
   <class '__main__.xfloat'>
   <class '__main__.xcomplex'>
Since coercion is getting axed in py3k, I don't think it makes sense to provide this behavior.

On the other hand, as you mentioned, the removal of coercion from complex could be backported.  However, if we are going to do that then we might as well just backport the whole removal of coercion instead of just the bits from 'complexobject.c'.  Bascially checkins r51431 and r58226.