> I would agree with Eli and Eric if it wasn't for that problem.

Agreed.  That was the gist of my question that led to Ethan's example.  If it's easy to accidentally break an enum, particularly in a subtle way, then it may not be worth taking a consenting adults approach.

Usually in consenting adults cases, it's simply not worth adding the extra complexity (or taking the time) to lock down an API or cover all the cases--it won't be a problem in practice since normal usage doesn't bear enough risk to worry about it.

In the case of enums, particularly in how they re-purpose classes and yet allow non-item attributes, there's a higher risk of accidentally breaking something during normal usage.  They quack like a class, but maybe they need to look less like a duck.  The question is, is the risk (and associated cost) of accidental breakage high enough to warrant the cost of being more heavy-handed?

> Also, we can first forbid overriding, then change our decision later
> on if someone comes with a use case (doing the converse would be more
> annoying as it would break compatibility).

+1