> Hmm, shouldn't self.__class__(self) be a 
> good default implementation of copy()?
>
> I'd expect any sequence to support this way 
> of creation from another sequence, even if it's inefficient.

The copy() method isn't being proposed for MutableSequence because it presumes that we know something about the constructor's signature.  For example, the constructor of array() needs the element storage type as an argument.  We refuse the temptation to guess.

In the Set api, we had no choice because many set-methods necessarily create a new set.  To handle the constructor signature problem, the creation step was factored-out into the from_iterable() method so that a user could override it if necessary.

Also copy() is handled oddly in the builtin types.  To handle the constructor signature issue for subclasses, they ignore the subclass and return a instance of the base class.  For example, the inherited copy() method on a subclass of list or dict will create an instance of list or dict, not of the subclass itself.  Accordingly, subclasses that want instances of themselves have to override the inherited copy() method.  They would have to do this anyway if they subclass contained any other data in the class dictionary that would need to be passed along to a copy.

In short, we're better-off not supplying copy() as part of the MutableSequence ABC.