Thank you Brian for your thoughts,

sorry for not having been concise, it seemed me to have needed to use the background.
For sure, dealing with multiple questions did not help me.

Anyway, for my first question, let me show the following example

(accepted by all main compilers: gcc, MVSC, Clang: https://godbolt.org/z/9aahnva64

 and I do not regret it)

template<typename T>

concept C = requires{ requires (requires{typename T::type;} || requires{T::value;}); };

template<C T>

void f(){};

struct S{

using type = int;

};

int main(){

f<S>();

}

Here, the normal form for C<S> is made by a single atomic constraint,
consisting in a requires-expression. In turn, it contains just a single nested

requirement for which the normal form is the logic OR of two atomic constraints

(they are requires-expressions, too), one of which contains an invalid expression.

(here above, note that I rely on the fact that no rule from [temp.constr.normal] discusses

 any substitution in case of requires-expression for an atomic constraint).

Now the point of my first question is around the formal definition of the immediate

context for the first atomic constraint.

I do believe that the requires-seq of the external requires-expression is not

part of that immediate context, but I am not sure I can find this from the standard text.
Please, help me.

In particular, my concern is about the fact that [temp.constr.atomic]-p3 reads

"If substitution results in an invalid type or expression in the immediate
context of the atomic constraint (13.10.3.1), the constraint is not satisfied."

whereas, [expr.prim.req.general]-p5 reads that the requirements in the requires-seq
of a requires-expression are checked one by one, not all soon together.

Unfortuantely, in the example above, in order to highlight the possible inconsistency,

I needed an OR combination so that we don't need the last expression to be valid

in order to get an overall true result for the external requires-expression,
but this also means that I am assuming the immediate context of the nested

requirement not to contain the ones of the inner requirement-expressions.

To summarize, I am just looking for any part of the standard, related to any

formal definition of the immediate context, or specifically associated to constraints

and requires-expressions, so that a clear separation of levels is made in hierarchies

as in my example.

In case some addition should really be needed, I consider the text

of [temp.deduct.general]-p9 as a possible model. It excludes the body of

a lambda from any immediate context involving it.
Such a clarification might be replicated (and adapted) in [temp.constr.atomic]

and/or in [expr.prim.req.general].