Proposed resolution (August, 2024):

1. Change in 7.3.2 [conv.lval] bullet 3.4 as follows:

   • Otherwise, the object indicated by the glvalue is read (3.1 [defns.access]), and the value contained in the object is the prvalue result. Let V be the value contained in the object. If T is an integer type, the prvalue result is the value of type T congruent (6.8.2 [basic.fundamental]) to V, and V otherwise. ...

2. Change in 7.6.1.6 [expr.post.incr] paragraph 1 as follows:

   The value of a postfix ++ expression is the value of obtained by applying the lvalue-to-rvalue conversion (7.3.2 [conv.lval]) to its operand. [Note 1: The value obtained is a copy of the original value. —end note] ...

3. Change in 7.6.19 [expr.ass] paragraph 2 as follows:

   In simple assignment (=), let V be the result of the right operand; the object referred to by the left operand is modified (3.1 [defns.access]) by replacing its value with the result of the right operand V or, if the object is of integer type, with the value congruent (6.8.2 [basic.fundamental]) to V.

(From submission #548.)

Subclause 7.2.1 [basic.lval] paragraph 11 specifies:

... If a program attempts to access (3.1 [defns.access]) the stored value of an object through a glvalue through which it is not type-accessible, the behavior is undefined. ...

Thus, access (read or write) to an int object using an lvalue of type unsigned int is valid. However, 7.3.2 [conv.lval] bullet 3.4 does not specify the resulting value when, for example, the object contains the value -1:

• Otherwise, the object indicated by the glvalue is read (3.1 [defns.access]), and the value contained in the object is the prvalue result. ...

Similarly, 7.6.19 [expr.ass] paragraph 2 is silent for the assignment case:

In simple assignment (=), the object referred to by the left operand is modified (3.1 [defns.access]) by replacing its value with the result of the right operand.

Any concerns about accesses to the object representation are handled in the context of P1839.