I understand the first part ("type is not specified"), but could you please elaborate on the second part?

http://eel.is/c++draft/basic.lval#def:result,glvalue, as usual

We seem to be not-quite-good with "result" throughout [expr], due to historical reasons.

Requests to fix such misuses are no (longer) accepted?

They are. A specific suggestion is appreciated.

Is the lack of type specification actually a problem, does it cause ambiguities? I'm not opposed to elaborating that, but I'd like to see a little more motivation.

@tkoeppe, every operator used to construct compound expressions should specify what type and value category the resulting compound expression has, and (when evaluated) what the value resulting from the operation is (plus any side effects etc.)

For assignment, we're lacking on the "type" part, which is simply a specification oversight / inconsistency. There's nothing ambiguous here.

For example, we say that 1+1 has type "int" (because the operands have type int, and (lots more mechanics)), but we don't say what the type of the compound expression "i = 1" is.

OK -- "omitted by oversight, inconsistent with other operator specifications" would be sufficient motivation. I'd welcome if that were part of the initial issue report.