> Either [...] we should lose the creation time check (not apply the transform), or we should still have the check (raise an error on invalid bits) which would still leave us in this situation.

That is only one option (which undesirable consequences are already identified).  We should consider a few options carefully.

From the start, if default Enum declarations are going to be subject to new runtime exceptions, it's certain that they'll be hit in some existing code.  Anything other than the default being legacy-compatible, or defining the new stuff as Enum2, or deferring all the changes to Python 4, is going to lead to bug reports and disgruntled users.  I don't think that suggests we should remove the runtime exceptions-- they are what supports the new API and implementation.

Perhaps KEEP should be renamed to LEGACY, that should be the default, and there should be guidance on how to get the KEEP use cases you've found migrated to one of the other modes.  (And changing the default could be considered for Python 4.)

>> But the [CONFORM] class members themselves should not have that transform applied, and raise
>> an error on invalid bits.
>
> But I'm not sure I understand that.

It's an important point that should be fixed in the code.  CONFORM should be regarding transforming external values into valid member instances.  The enum author's declaration itself should be coherent and not rely on such transforms.  Users will be surprised when they define a "FOO = 0xFF" and they read the value back as 0x1F or something.  The runtime exception lets the enum author know about the issue in the declaration, and normalize it.