Let me start with where we agree. I agree that 6.5.16.1 p3 deserves
some clarification. After that however my reading and yours reach
different conclusions.
First I think the passage as written clearly conveys the meaning
intended in this case, that this assignment is undefined behavior.
The value being stored was read out of x.i, and is being stored
into x.c. The types of those two objects don't mesh, and so the
assignment is undefined behavior. This assignment is about the
clearest possible case that would violate 6.5.16.1 p3, and the
passage as written conveys that, IMO with no room for argument.
Second I think whether the RHS is an lvalue has no bearing on the
question. The cited paragraph does not mention anything about
lvalues; it speaks only of "the value being stored". Consider a
slight variation:
x.c = (printf( "hello world\n" ), x.i);
The RHS of this assignment is not an lvalue. But the /value/
being stored was read from x.i. As I read the Standard this
assignment too is undefined behavior, and IMO the Standard does
convey that intention.
Here is another variation:
x.c = 0 ? printf( "hello world\n" ) : x.i;
Once again the value being stored was read from x.i, and again
as I read the Standard this assignment too is undefined behavior,
and IMO the Standard does convey that intention.
Now let's look at an example you give in your stackoverflow answer.
Quoting a whole paragraph:
The passage says that the value "is read from another
object". That's ambiguous. Must name of the object be the
entire RHS expression, or can it be just a subexpression?
If the latter, then x.c = x.i + 1; would have undefined
behavior, which in my opinion would be absurd.
You left out an important part: "the value /being stored/".
Here the value being stored is x.i + 1. That /value/ was not
read from x.i; it was formed by an addition operation after
reading x.i. Ostensibly this assignment would not be undefined
behavior. I say "ostensibly" because actually I think this case
is not clear, and may have been intended to be undefined behavior
along with the others. And I don't see anything absurd about
having it be undefined behavior, or even surprising if it were
discovered that this case had been meant to be undefined behavior
all along.
Disclaimer: I haven't yet done any research into Defect Reports
or committee meeting notes to see if this question has been
addressed there. I suspect it has, but I just haven't looked
yet.