That's not true if Z is a class type.

The example is incorrect anyway. Whatever the object X[ {1,2,3} ] of type Z is, it will never be updated with the object Z(7), as the object X[ {1,2,3} ] is destroyed at the end of the expression X[ {1,2,3} ] = 7; , if the return of X::operator[](std::initializer_list<int>) is not an lvalue reference. In other words, even for a class object,, a subscript operator has to return an lvalue reference, if it's going to be used to update an object of its own class.

Z could be a proxy object that refers back to the X that created it. It could even be X&. It's not relevant to the example, and the example doesn't need to be a complete, working program doing something useful.

To expect someone to guess that Z could be a proxy object referring back to X in the alluded example, contributes to the aura that the Standard already has nowadays, i.e., of an unintelligible document, to the point that sometimes it seems to have mystifying purposes.

Nobody is expected to guess that, because it's not relevant to the example. You have twice stated the example is invalid code and I've provided evidence to the contrary in the form of suggestions for the type not shown in the example.

It doesn't matter exactly what Z is, or whether the example could usefully update x. That's not the point of the example.

Z could also be typedef for int&

The point is you don't need to know what it is, because that's not what the example is about. The overloaded operator returns something that can be on the left hand side of an assignment. There are types that make that valid, so stop assuming it's a type that makes it invalid.