> Ignoring all the other things being discussed, regardless of positions people are taking,
> this seems a strange thing to permit.
> I assume it’s just what falls out of having an integral representation,
> but I feel like it would have been worth making a carveout to disallow this.

I don't see any obvious problem with bit-fields of type _BitInt, and
neither did WG14 I suppose.

> I’m sure there’s an element of allow _BitInt(32) to be interchangeable with int32_t,
> but my _understanding_ (which I accept may well be wrong) is that it is not considered the same,
> in the sense that _BitInt(32)* could not alias int32_t*?

That's right; none of the <cstdint> aliases can be bit-precise
integers, and strict aliasing disallows you from treating bit-precise
integers and standard integers interchangeably, even if they have the
same representation.

> Also to be clear: I am not advocating we diverge from C here,
> as I think there is value to maintaining compatibility between the languages even if some folk do not,
> and of course we will be expected to handle C struct definitions no matter what we might say in the standard.

Yeah, our hands are mostly tied here. The proposal is a C
compatibility proposal first and foremost, and it would be an utter
failure if we still can't interface with the C ABI following the
proposal, even if the incompatibility is limited to somewhat uncommon
structs like these bit-fields.

To my knowledge, the only thing we cannot properly interface with at
the ABI level are C-exclusive types like _Decimal64 (although you
could make a C++ class that has the same representation as a
workaround), as well as flexible array members (but these would take a
lot of effort to get into C++, including much wording effort, unlike
bit-fields, which work with bit-precise integers without any special
mention).