Allowing bit-precise integer types as fixed underlying type for enums helps avoid leaving bit-precise integer types and enums with fixed underlying type underdeveloped. Since it just lifts a restriction, it also keeps the language simple, and allows further programming freedom.
The use of bit-precise integer types is exlicitly forbidden in a few places in the standard. One of these is the user's choice of a fixed underlying type for enum.
Many of these restrictions were added into the standard a while after bit-precise integer types were added to the standard. I wanted to have fewer such restrictions, but WG14 disagreed. AFAIR, the discussions then were focused on two aspects: bit-precise types don't promote to int, and bit-precise types might be inefficient if their width is not a multiple of the word width of the architecture; both of these might result in bad surprises to the user.
Forbidding bit-precise types as fixed underlying type for enum is different: this restriction existed from the moment fixed underlying types for enum were introduced. The reasoning is in N3030, section 4.2, and is mostly the open question if enum with bit-precise type as fixed underlying should undergo integer promotion. Close in time, N2969 was accepted, which allowed bit-precise integer types in bit-fields, and for those, the question of integer promotion was resolved, such that bit-fields of bit-precise integer types do not undergo integer promotion.
Thus, it would be consistent, to have enum with bit-precise fixed underlying type also not promote to int. Also, since the underlying type is chosen by the user, it would not be a surprise to the user that the enum does not promote to int, and if the user chooses a bit-precise type of a width that is not a multiple of the word width of the underlying architecture, a possible performance penalty would also not be surprising. Using a bit-precise type integer type as fixed underlying type for an enum is an intentional choice, opting for the semantics of the bit-precise type.
Since SDCC 4.5.7, SDCC supports this feature (in --std-sdcc23 and --std-sdcc2y modes; in --std-c23 mode the required diagnostic for the constraint violation is a warning).
Proposed changes (vs C2y draft N3550):
In 6.3.2.1p2, replace
"If the original type is not a bit-precise integer type (6.2.5): if an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int;"
by
"If the original type is neither a bit-precise integer type (6.2.5) nor an enumerated type compatible with a bit-precise integer type: if an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int;"
In 6.7.3.3p5, replace
"It shall name an integer type that is neither an enumeration nor a bit-precise integer type."
by
"It shall name an integer type that is not an enumeration."