I'm not sure which promises you're referring to Nick, and to whom they were made; the only formal promise we made is PEP 435 - and it doesn't mention this extensibility.

I won't argue beyond this comment, since I know I'm part of the minority opinion here. However, I still think this is a mistake.

The most important original goal of Enum (as discussed during the language summit) was to replace all the custom enum implementations by one that is standard. A far fledged extension mechanism will just make it so we'll have a fleet of bastardized "extended enums", each with its own capabilities, each different from the others. With one standard Enum, when you're reading someone's code and you see:

class Foo(Enum):
  ...

You know very well what Foo is. Restricted extensions like IntEnum and even your @enum.unique are still tolerable because they're explicit:

# enum.unique is standard and says what it is explicitly
@enum.unique
class Foo(Enum):
  ...

But if we open the gates on customization, we'll have:

class Foo(AutoEnum):
  Red, White, Black

And:

class Bar(SomeOtherAutoEnum):
  Red = ...
  White = ...
  Black = ...

And:

class Baz(SomeEvenOtherMagicEnum):
  ... # whatever goes here

And we're back to square 1, because these Enums are not standard, and each framework will have its own clever customization one will need to understand in order to read code with Enums.

Exposing and documenting the metaclass and customizations of __new__ is a whole coffin for the "there is only one way to do it" decision of stdlib's Enum. It might have been better to just define AutoNumberedEnum, BitfieldEnum and Magic42Enum as part of the enum package in stdlib and be over with it; but this was strongly rejected by others and particularly Guido during the summit and later. Now we're just creating a back-door to get into the same situation.