Hello Antoine.
1) Yes, I am not completely happy with the approach myself, but I'd like to get the ball rolling.  One particular nuance is that there appears to be a way to provide a custom MRO, one which does not enforce the rule that the self type come first.
(although, in the code there is a place that iterates over the mro tuple starting from index 1... the code isn't completely consistent.)

An alternative approach, that would replace 'self' in the mro with Py_None, and then special casing this when doing lookup, might that be ok?

2) I was a bit worried about it, but running the test suite showed no problems.  The only time this weak reference gets dropped is when the class is garbage collected, hence the need to add special code to repr the descriptor.  The descriptors are normally part of the class, and then de-referenced at runtime into concrete things, such as bound methods, and the like.  I suppose we could float this on python-dev, to see what people think.

3) thanks for the heads up.  it looked a bit weird to me.  But python 3 code is still getting the shakedown, and touching these parts of the code can illustrate unknown bugs.  There are some other assumptions I came across in the code that are weird, but don't appear to be relevant. In one place, it is presumed that tp_mro could be NULL, but later, it is INCREFd.  And in another place, (descriptors) the type is XINCREFd, but then in other places, assumed to be true....

Anyway, I'd like us to find a way to do this in a clean way.  I'll revisit the macro scheme, and see if I can do it more nicely and explicitly.