Possible resolution:

1. Change in 6.9.2 [basic.types.trivial] paragraph 1 as follows:

   Each trivially copyable type T has an implementation-defined set of discrete values. Each possible value representation of an object of type T corresponds to a distinct implementation-defined subset of this set. The union of these subsets is the set of values; for scalar types other than object pointer types, each such subset contains no more than one value. Certain operations cause an object o to acquire a value representation, in which case the object's value is replaced as follows:

   • For each bit b in the value representation that is indeterminate or erroneous, the smallest object enclosing b has indeterminate value if any of the bits in its value representation are indeterminate, or otherwise has an erroneous value. No other subobject of o (if any) has indeterminate or an erroneous value.
   • Within these constraints, the value of o is with an unspecified member , if any, of the corresponding subset that would result in corresponding to the value representation, selected such that the program having would have defined behavior, if any possible.

2. Change in 22.11.3 [bit.cast] paragraph 3 as follows: (remove rules now redundant with "acquire a value representation"; the entire result is trivially copyable per the constraints)

   Returns: An object of type To. Implicitly creates objects nested within the result (6.8.2 [intro.object]). Each bit of the value representation of the result is equal to the corresponding bit in the object representation of from. Padding bits of the result are unspecified. Every trivially copyable object among the result and each object created within it acquires the value representation produced; if any such object does not receive a value, the behavior is undefined. A bit in the value representation of the result is indeterminate if it does not correspond to a bit in the value representation of from or corresponds to a bit for which the smallest enclosing object is not within its lifetime or has an indeterminate value (6.8.5 [basic.indet]). A bit in the value representation of the result is erroneous if it corresponds to a bit for which the smallest enclosing object has an erroneous value. The result acquires (6.9.2 [basic.types.trivial]) the value representation produced. If any object among the result of other than unsigned ordinary character type or std::byte type has indeterminate value, the behavior is undefined. Otherwise, if any object among the result has erroneous value, the behavior is erroneous. For each bit b in the value representation of the result that is indeterminate or erroneous, let u be the smallest object containing that bit enclosing b:

   • If u is of unsigned ordinary character type or std::byte type, u has an indeterminate value if any of the bits in its value representation are indeterminate, or otherwise has an erroneous value.
   • Otherwise, if b is indeterminate, the behavior is undefined.
   • Otherwise, the behavior is erroneous, and the result is as specified above.

   The result does not otherwise contain any indeterminate or erroneous values.

(From submission #980.)

An unsigned char value that is indeterminate is not immediately causing undefined behavior per 6.8.5 [basic.indet]. When std::bit_cast is applied to such a value, converting to an unsigned char type, the "acquire a value representation" wording in 6.9.2 [basic.types.trivial] paragraph 1 is not equipped to handle the situation.

Furthermore, consider:

  #include <cstring>

  int main() {
    int x = 42, *p = &x, *q = p + 1;
    std::memcpy(&p, &q, sizeof(p)); // giving `p` the value of `q` would _not_ lead to the
	       // program having defined behaviour
    return *p; // Is the value of `p` here still `&x`? Prior to P2434R5, no.
  }