> The operator methods in setobject.c should be liberalized to accept
> instances of collections.Set as arguments.

Under this plan, set() and collections.Set will still have slightly different behavior.  collections.Set will be more liberal and accept any iterable.  Are you okay with that?  I don't feel strongly about this point; I just want to make sure it's a conscious decision.

I do feel strongly that set and collections.Set should be able to inter-operate nicely and the proposal satisfies that requirement so I would be happy with it.

> To implement PyObject_IsInstance(other, collections.Set), there may
> be a bootstrap issue (with the C code being compiled and runnable
> before _abcoll.py is able to create the Set ABC). Alternatively, 
> the code in setobject.c can lazily (at runtime) lookup 
> collections.Set by name and cache it so that we only do one
> successful lookup per session.

I favor the lazy lookup approach.

> Whatever approach is taken, it should be done with an eye towards 
> the larger problem that Python is filled with concrete isinstance()
> checks that pre-date ABCs and many of those need to be liberalized
> (accepting a registered ABC and providing different execution paths
> for known and unknown concrete types).

Agreed.  Ideally, the "PyObject_IsInstance(other, collections.Set)" logic would be abstracted out as much as possible so other parts of Python can make similar checks without needing tons of boilerplate code in every spot.

For what it's worth, I don't think we will find as many inconsistency issues with ABCs other than Set.  Set has methods that take another Set and return a third Set.  That forces different concrete implementations of the Set ABC to interact in a way that won't come up for a Sequence or Mapping.

(I suppose that Sequence.extend or MutableMapping.update are somewhat similar, but list.extend and dict.update are already very liberal in what they accept as a parameter.)