Possible resolution:

1. Change in 6.9.1 [basic.types.general] paragraph 11 as follows:

   Two types cv1 T1 and cv2 T2 are layout-compatible types if T1 and T2 are the same type, layout-compatible enumerations (9.8.1 [dcl.enum]), or layout-compatible standard-layout class types (11.4 [class.mem] 11.2 [class.prop], 11.4.1 [class.mem.general]).

2. Remove 11.2 [class.prop] paragraph 4:

   A standard-layout struct is a standard-layout class defined with the class-key struct or the class-key class. A standard-layout union is a standard-layout class defined with the class-key union.

3. Add a new paragraph before 11.4.1 [class.mem.general] paragraph 27, change paragraph 27 as follows, and de-bulletize:

   Two non-static data members or bit-fields are layout-compatible if

   • they have layout-compatible types (6.9 [basic.types]),
   • they have the same alignment requirements (6.8.3 [basic.align]),
   • if a has-attribute-expression (15.2 [cpp.cond]) is not 0 for the no_unique_address attribute, then neither entity is declared with the no_unique_address attribute (9.13.11 [dcl.attr.nouniqueaddr]), and
   • either both entities are bit-fields with the same width or neither is a bit-field.

   The common initial sequence of two standard-layout struct non-union class (11.2 [class.prop]) types is the longest sequence of non-static data members and bit-fields in declaration order, starting with the first such entity in each of the structs classes, such that

   • corresponding entities have are layout-compatible types (6.9 [basic.types]),.
   • corresponding entities have the same alignment requirements (6.8.3 [basic.align]),
   • if a has-attribute-expression (15.2 [cpp.cond]) is not 0 for the no_unique_address attribute, then neither entity is declared with the no_unique_address attribute (9.13.11 [dcl.attr.nouniqueaddr]), and
   • either both entities are bit-fields with the same width or neither is a bit-field.

   [ Example: ... ]

4. Change and merge in 11.4.1 [class.mem.general] paragraph 28 and paragraph 29 as follows:

   Two standard-layout struct class (11.2 [class.prop]) types are layout-compatible classes if

   • neither is a union and their common initial sequence comprises all non-static data members and bit-fields of both classes (6.9 [basic.types]) or
   • both are unions and Two standard-layout unions are layout-compatible if they have the same number of non-static data members and bit-fields and corresponding non-static data members entities (in any order) have are layout-compatible types (6.9.1 [basic.types.general]).

5. Change in 11.4.1 [class.mem.general] paragraph 31 as follows:

   ... [Note 11: There can therefore be unnamed padding within a standard-layout struct non-union class object inserted by an implementation, but not at its beginning, as necessary to achieve appropriate alignment. —end note] ...

6. Change in 11.5.1 [class.union.general] paragraph 2 as follows:

   ... [Note 1: One special guarantee is made in order to simplify the use of unions: If a standard-layout union contains several standard-layout structs non-union classes that share a common initial sequence (11.4 [class.mem]), and if a non-static data member of an object of this standard-layout union type is active and is one of the those standard-layout structs non-union classes, the common initial sequence of any of the those standard-layout struct non-union class members can be inspected; see 11.4 [class.mem]. —end note]

7. Change in 21.3.11 [meta.member] paragraph 4 as follows:

   Returns: true if and only if S1 and S2 are standard-layout struct non-union class (11.2 [class.prop]) types, M1 and M2 are object types, m1 and m2 are not null, and m1 and m2 point to corresponding members of the common initial sequence (11.4 [class.mem]) of S1 and S2.

8. Change in 32.5.8.1 [atomics.types.generic.general] paragraph 2 as follows:

   The specialization atomic<bool> is a standard-layout struct class (11.2 [class.prop]). It has a trivial destructor.

9. Change in 32.5.8.3 [atomics.types.int] paragraph 2 as follows:

   The atomic integral specializations are standard-layout structs classes (11.2 [class.prop]). They each have a trivial destructor.

10. Change in 32.5.8.4 [atomics.types.float] paragraph 2 as follows:

    The atomic floating-point specializations are standard-layout structs classes (11.2 [class.prop]). They each have a trivial destructor.

11. Change in 32.5.8.5 [atomics.types.pointer] paragraph 1 as follows:

    There is a partial specialization of the atomic class template for pointers. Specializations of this partial specialization are standard-layout structs classes (11.2 [class.prop]). They each have a trivial destructor.

12. Change in 32.5.10 [atomics.flag] paragraph 3 as follows:

    The atomic_flag type is a standard-layout struct class. It has a trivial destructor.

(From submission cplusplus/draft#8787.)

References: common initial sequence and layout-compatible (11.4.1 [class.mem.general] paragraph 27)

Consider:

  struct A { int x; };
  struct B { int x; void foo(){} };

These types are not layout-compatible, because 11.4.1 [class.mem.general] paragraph 28 considers all members, not just non-static data members:

Two standard-layout struct (11.2 [class.prop]) types are layout-compatible classes if their common initial sequence comprises all members and bit-fields of both classes (6.9 [basic.types]).

Furthermore, the definition of layout-compatible unions is lacking consideration of bit-field length, [[no_unique_address]], and unnamed bit-fields.