Is the value representation of integral types implementation-defined or unspecified?

To quote from N4868 6.8.2 paragraph 5:

Each value x of an unsigned integer type with width N has a unique representation...

Notably, it avoids specifying "value representation" or "object representation," so it's not clear if either is intended here.

Later on (in the index of implementation-defined behavior), N4868 does call out the value representation of pointers and of floating-point types as implementation-defined, but very notably excludes integral types.

Given this, there are four potential interpretations that I can think of:

1. The value representation of integral types is uniquely specified
2. The value representation of integral types is unspecified
3. The value representation of integral types is implementation-defined, but mistakenly left out of the aforementioned index
4. The value representation of integral types is undefined

#1 appears impossible, as implementations exist for both big- and little- endian architectures.

#3 appears unlikely, since the absence of integral types from the index is conspicuous, and the actual text of both floating-point and pointer types calls out their being implementation-defined, while the text on integral types goes to great lengths to avoid specifying the value representation.

#2 is the most likely interpretation, but is conspicuous in that the standard often calls out behavior as unspecified, but here says no such thing. This would, among other things, imply that behavior can be unspecified even if not actually called out as such, which makes it difficult to distinguish merely unspecified behavior vs behavior that is left undefined by the standard not defining it at all (as opposed to called out as "undefined behavior")

#4 seems absurd, as the standard implies that all types (or at least, trivially-copyable ones) have a definite, if otherwise unspecified, object representation (and by extension, value representation). Specifically, 6.7, paragraph 4 states:

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.

Which seems to imply that the value representation of trivially-copyable types (including integral types) is otherwise unspecified.

Scenario #2 probably indicates a failure to call the representation out as "unspecified," since we have the note under the definition of "undefined behavior" in Section 3: "Undefined behavior may be expected when this document omits any explicit definition of behavior." If the value representation of integral types isn't every explicitly stated as unspecified / implementation-defined, then code that depends on the value representation wouldn't just be unspecified / implementation-defined, it would be undefined by omission.

However, one could also argue that the "explicit definition of behavior" clause does not apply, as the behavior is perfectly well-defined, the object representation being a sequence of objects of type unsigned char, with merely their values being left to the implementation.