> I would expect the and operation between my set implementation 
> and a string to fail with a TypeError, given that string is 
> not an instance of Set. However, the error is not raised ...

Odd as it may seem, this isn't a bug; rather it was a deliberate design decision by GvR.  Regular sets have a intersection() method that accepts any iterable.  In contrast, the Set abstract base class doesn't have a intersection() method and instead uses __and__() to do the work.

While there is room to have debated whether that design decision was a good one, that ship sailed long ago.  Tightening the input requirement now would almost certainly break existing code and would take away needed functionality.

Alternatively, we could liberalize set.__and__ to make it accept any iterable (to match the ABC), but Guido advised against this based on his bad experiences with list.__iadd__ accepting any iterable (for example:   s = ['abc', 'def']; s += 'def').  I think he's right that such an amendment would be a bug factory.

You'll likely find a number of places where the collection ABCs differ in minor details from various concrete classes.  In almost every case, you'll find a reason for the choices that were made.  It hasn't been a problem in practice unless someone (like the OP) expects that the ABCs have higher fidelity and can used to reimplement all of the details of the related concrete class (i.e. expecting to use Set() to match all the concrete implement nuances tested in Lib/test_set.py).