> In which case: consider this a feature request to 
> consider adding __slots__ ...

A few thoughts:
* Enumerations tend to be small, so a space savings likely isn't relevant.
* In Python 3.11, the speed advantage of slots is now much smaller.
* The code for Enum is already complex and has a lot of magic.  Adding slots to the equation may make it even harder to reason about the internals.
* It not even clear that __slots__ would or could play nice with existing code.  Even if it does, it may tie our hands for other avenues of development such as a custom a __getattribute__ or use of @cached_property.

Please consider a more use case driven development approach to working on the core.  We have no known problems with Enum at this point that need to be solved.  A general notion that __slots__ should be used in more places is a reasonable topic for python-ideas.  The tracker is more suitable for targeted proposals like, "my company needs enums to work with tool x but it won't unless slot support is added", "my real-world app must support enormous enumerations that lead to memory problems unless slots are added", "i tried adding slots to Enum and found it was easy, didn't cause problems, and sped-up common cases by 22%".

I mostly agree with Christian except that limiting attribute access is a legitimate reason to use slots.  However, in the case of Enums that isn't a known issue.  Also, it is something that would need to done when a tool is first released.  Generally, we can't add it afterwards because that would be a breaking change (some applications may be legitimately adding additional attributes).

For now, I'll close this.  If Ethan thinks there is some fruit on this tree, he can reopen it.  Also if a specific real world use case arises, it can be reopened.