> encourage the common assumption that locals() returns a dict where mutating it actually works, since it usually doesn't.

It does at global and class scope, not at function scope.

FWIW, PEP558 (admittedly not accepted yet) proposes to modify the documentation for the semantics of locals() at class-scope to match the actual behavior (https://www.python.org/dev/peps/pep-0558/#class-scope):

    At class scope [...] changes to the returned mapping must change the values bound to local variable names in the execution environment.

> I'm worried that making _EnumDict inherit from collections.abc.MutableMapping in general would slow down Enums (at the very least creation, I'm not clear on whether _EnumDict remains, hidden behind the mappingproxy, for future lookups on the class), since MutableMapping would introduce a Python layer of overhead to most calls.

"Normal" calls won't: __setitem__ / __getitem__ stays what they are, they were implemented in Python and stay implemented in Python.  Whoever calls update() will go through an extra Python layer, but there's not much you can do about that.

Alternatively, if you *really* don't want to support the MutableMapping API, at least it should be disabled (e.g. by adding stub implementations of update(), etc. that throw NotImplementedError).  Again performance-wise this would only affect those who try to call these methods.

As a side note, I would be curious to see any realistic code where the performance of enum creation turns out to be critical.  I don't think(?) the _EnumDict stays afterwards, at least PEP558 (which supposedly corresponds to the actual current behavior) also states "The mapping returned by locals() will not be used as the actual class namespace underlying the defined class (the class creation process will copy the contents to a fresh dictionary that is only accessible by going through the class machinery)."