@thephd 6. It would be nice to have better handling in the standard for situations where one structure type is an "extended" version of another, with extra members added. Maybe out of scope for this proposal, but it seems potentially related.

@thephd 5. Can named and unnamed bit-fields match each other when using _Record(types)? I think the answer is yes based on the proposed wording, but this gives rise to a slightly odd situation where two compatible structure types may have different numbers of initializable members. Whatever the answer winds up being, I'd suggest including an example.

@thephd 4. Please make sure the standard wording reflects what you intend with regard to the interaction between _Record and anonymous structures and unions. For example, can an anonymous structure or union in a structure type declared with _Record(types) match with a named member of another for type compatibility purposes? I'd suggest including examples of these cases. (Also, your document seems to use "anonymous structure" differently from the definition in the standard, which is confusing.)

@thephd 3. I'm not entirely convinced that having _Record, _Record(types), and potentially _Record(other::attributes) is valuable enough to justify the complexity of it. I'd be tempted to just specify one version and leave any implementation-specific variants up to the regular attribute syntax.

@thephd 2. I'm not sure _Record is a good name for it. To me, this calls to mind records in Pascal, which are essentially its version of structures and/or unions and do not have structural compatibility rules. The term "record" is also used in several other programming languages and in databases, often not with the meaning you're giving it. A possible alternative that comes to mind is "tuple", although that corresponds most naturally to what you call _Record(types).