> I don't understand the rationale for this change in depth, but
> does the benefit outweigh (yet another) backwards incompatibility?

I think you can have it both ways.  Do you want a C API that is
stable over a long period of CPython releases or do you want to
continue to be able to look deep (i.e. non opaque PyObject*) into
CPython implementation internals?

During the sprint last week, we talked about how to provide a
compatible API, similar to what Pypy cpyext does.  It would be
possible to provide a (nearly) fully compatible API with the
approach.  It could get quite painful for CPython to maintain such a
thing however.  E.g. cpyext has proxy objects (to maintain CPython
compatible structure layouts) but keeping those proxies in sync with
the internal VM object structures is expensive and tricky.

Certainly making PyObject opaque is going to break some 3rd party
code.  Making it opaque for the non-limited API is not an option
IMHO because it breaks too much 3rd party code.   Is making it
opaque for the limited C API going to break too much code?  Maybe, I
don't know.  Thanks for pointing out pycurl and breezy.