[expr.prim.id.unqual] p3 Improve the utterance: "contain" vs. "in"

[expr.prim.id.unqual] p3

The result is the entity denoted by the unqualified-id ([basic.lookup.unqual]). If the unqualified-id appears in a lambda-expression at program point P and the entity is a local entity ([basic.pre]) or a variable declared by an init-capture ([expr.prim.lambda.capture]), then let S be the compound-expression of the innermost enclosing lambda-expression of P. If naming the entity from outside of an unevaluated operand within S would refer to an entity captured by copy in some intervening lambda-expression, then let E be the innermost such lambda-expression, and:

• If P is in E's function parameter scope but not its parameter-declaration-clause, then the type of the expression is the type of a class member access expression ([expr.ref]) naming the non-static data member that would be declared for such a capture in the object parameter ([dcl.fct]) of the function call operator of E.
• Otherwise (if P either precedes E's function parameter scope or is in E's parameter-declaration-clause), the program is ill-formed.

Otherwise, the type of the expression is the type of the result.

Since we define a concept that An enclosing scope at a program point is any scope that contains it; in [basic.scope.scope] p1. I think we should consistently use "contain" instead of "in". Simultaneously, "in" is not clear to state the intent of the above provision. Consider the formal example in P2036r3

int j;
[=](){
    (decltype((j)) w)  // ok: as above, 'w' is a parameter of type int const&
    {};
};

I would say point P is exactly in the function parameter scope of the inner lambda, which in turn is "in" the function parameter scope of the outer lambda. Does the intent of "in" includes "indirectly in"? Hence, "contain" can work well and is more formal than "in".

Consider the second emphasized sentence. It's hard to understand what the sentence means. According to the inspiration of the note after the rule, I think it is better to be expounded with that:

..., then the type of the expression is the type of a class member access expression ([expr.ref]) naming the non-static data member that would be declared for such a capture, where the object expression is the object parameter ([dcl.fct]) of the function call operator of E.

Incidentally, consider the following case, which is impacted by the modification of P2036r3

int t = 0;
auto f = [x = t, b = sizeof(x)](){};

According to [expr.prim.lambda.capture] p6

An init-capture inhabits the function parameter scope of the lambda-expression's parameter-declaration-clause.

Both init-captures are in the function parameter scope of the lambda but not in its parameter-declaration-clause, hence, [expr.prim.id.unqual] p3.1 is exactly applied to this case. However, such a case is rejected by all implementations.

Start with [expr.prim.id.unqual] p3 and compare its use of “in” with [basic.scope.scope] p1 and [expr.prim.lambda.capture] p6. Read the cited P2036r3 example and check the reported init-capture case against current implementation behavior. Done means resolving the scope wording and clarifying the object-parameter sentence without changing the intended rule.