FWIW, I'm happy with Guido's design of MutableMapping.  It parallels all
the other ABCs in its design and it succeeds completely at its primary
role as a defining an interface.  Its secondary role is to provide some
mixin capability.  It does well in this role when used as documented
(just filling-in the abstract methods as letting the mixin do the rest).

The case with OrderedDict is not a typical use of mixins because the
primary class (dict) already provides all of methods demanded by the
interface.  I explicitly overwrite some of dict's methods because that
is part of the behavior that OrderedDict wants to define differently
than dict.  It is appropriate that the primary class gets first dibs on
defining a method and that intentional overrides are done explicitly (as
they are in the OrderedDict example).

With OrderedDict, the only reason we subclassed from dict was to provide
interoperability with third-party tools that may have been hardwired to
work only with dicts.   In general, the preferred approach is to not
subclass both dict and OrderedDict and to let the MutableMapping
interface do its job.

The proposed splitting of MutableMapping looks unhealthy and overly
complex to me.  It makes ABCs harder to use in the general case just to
make one special case look a little prettier and do more of its magic
implicitly.

If this *really* bugs you, OrderedDict doesn't have to inherit from
MutableMapping at all.  We can throw code reuse out the window and just
duplicate the relevant code fragments.  To my eyes, either way is an
explicit override of the dict's methods which is the intended effect.

FWIW, the UserDict class in Py3.x was relocated to the collections
module.  It isn't gone.  We made an effort to kill it but found that
there were compelling use cases that were not a cleanly solved by any
other approach.