Possible resolution:

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

The object representation of a complete object type T is the sequence of N unsigned char objects taken up by a non-bit-field complete object of type T, where N equals sizeof(T) (7.6.2.5 [expr.sizeof]). ... For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values. [ Footnote: ... ]

For any complete object type, its size and the presence and placement of padding does not vary within a program. [ Note: In particular, these properties are not affected by constant evaluation (7.7 [expr.const]). -- end note ]

The size of an object depends on the implementation (7.6.2.5 [expr.sizeof]). Similarly, the size and location of padding depends on the implementation (6.9.1 [basic.types.general] paragraph 4).

Equality-comparing pointers compares their addresses (independent of provenance) (7.6.10 [expr.eq] paragraph 3), which makes the padding choices of implementations observable. Reflection facilities provide similar means. Note that such address comparisons need to be supported only within a single complete object, not across complete objects (see also issue 2765).

It is intended that the implemenation can choose size and padding per type and per program, but these choices cannot vary for a given type within a single program. However, there is insufficient specification to that end. The question arises in particular whether equality-comparing pointers to subobjects (or elements of the object representation) at compile time and at runtime is permitted to yield different outcomes.