The category of constraints introduced in a requires expression is not clear. Such as [expr.prim.req.nested]

A nested-requirement can be used to specify additional constraints in terms of local parameters.

we just define three kinds of constraints in [temp.constr.constr]

There are three different kinds of constraints:

• conjunctions,
• disjunctions, and
• atomic constraints.

Consider this example associated with nested-requirement

template<typename T> concept C = requires (T a) {
     requires sizeof(a) >0 || true;      
};

sizeof(a) >0 || true is a constraint-expression but not a constraint. In this case, we also cannot know what kind of constraint the expression is. Presumably, the normalization should apply to these expressions to bring them to be the formal constraints.

A similar issue also exists in other kinds of requirements. [expr.prim.req.compound] p1

The immediately-declared constraint ([temp.param]) of the type-constraint for decltype((E)) shall be satisfied.

Again, what's the kind of that constraint? if the type-constraint's constraint-expression has the form E1 || E2, E1 && E2 or ( E ). Moreover, "is satisfied" is only defined for constraints, and we only define how the constraint is satisfied in [temp.constr.constr] for three kinds of formal constraints. We might make the normalization apply to all expressions when we want to say the constraint shall be satisfied.