[bit.endian] says that "big-endian" and "little-endian" refer to whether bytes are stored in descending or ascending order of significance. In other words, when std::endian::native is either std::endian::big or std::endian::little, we are told something about the object representations o f multi-byte scalar types. However, the guarantee provided in this case is not strong enough to fully specify the object representation, even in the common situation where padding bits are not present. It would be more useful to provide a stronger guarantee.

Consider, for example, if char is 8 bits and there is an uint32_t type on the current platform. If std::endian::native is std::endian::little, then the program should be able to rely on the fact that if a uint32_t object is copied into an array of 4 unsigned char, then the value of the first element of that array actually equals the original value modulo 256. However, because P1236R1 removed the core language specification of the value representation of unsigned integer types, the program cannot actually rely on this. It is conceivable (though unlikely), for example, that std::endian::native could be std::endian::little but the first byte in a uint32_t object is actually the least significant 8 bits flipped, or the least significant 8 bits permuted, or something like that.