Dissolve [over.oper]

The subclause on operator overloading should be integrated into the sections where it belongs.

Restrictions on declaring operator functions (e.g. no default arguments) should be moved to [dcl.fct], where other restrictions on function declarations are located. We might want to split up [dcl.fct] into "function types", "function declarations", "operator functions" or so.

The actual expression rewrite (where e.g. @ cast_expression is turned into a call to cast-expression.operator@) should go into [expr.compound], near the description of the actual operator syntax. Some additional grouping might be advisable for a compact representation. For example, [expr.mul] through [expr.log.or] should be grouped under "Binary expressions".

[over.built] should also go under [expr].

This makes [expr] a lot more self-contained and clearly attaches the grammar presentation there to the complete semantics, in lieu of the hand-wavy note in [expr.pre] p2 pointing to [over.oper]. Currently, you match the grammar in [expr.compound], then do overload resolution as explained in [over.oper] (without pervasive cross-references), then you jump back to [expr.compound] for the built-in meaning, hitting seemingly out-of-place gems such as [expr.sub] p4 "A braced-init-list shall not be used with the built-in subscript operator."

Start by reading the issue alongside [over.oper], [dcl.fct], [expr.compound], [over.built], and [expr] in the draft. Map the operator restrictions, expression rewrite, and built-in operator semantics to their proposed sections. Done means the material is integrated without the current cross-references or misplaced semantics, with grouping and section organization resolved.