I'd support this rephrasing, although I suggest beginning with "T models Blargh only if, ..." (or "X, Y, and Z model Flurb<X, Y, Z> only if, ..." for multi-parameter concepts).

We probably need to be careful about the interaction between "for any" and our handwavy "domain" wording.

Yes, it would probably make sense to make the "satisfied" -> "models" change together with this one, and I think your approach seems mostly reasonable. The inconsistency between "T models Blargh" and "X, Y, and Z model Flurb<X, Y, Z>" bothers me, though -- we should either consistently put a template-id on the right-hand-side or a concept-name. Do either of these seem OK:

1. "T models Blargh<T> only if [...]" and "X, Y, and Z model Flurb<X, Y, Z> only if [...]" (that is, a sequence of template arguments are said to model a template-id with that sequence of arguments)
2. "T models Blargh only if [...]" (or synonymously, "Blargh<T>" is modeled only if [...]") and "Flurb<X, Y, Z> is modeled only if [...]" (that is, a template-id whose template-name is a concept is either modeled or not modeled; if there is only one template-argument, that template-argument is said to model the concept).

we should either consistently put a template-id on the right-hand-side or a concept-name.

I've found several occurrences in P896 where it's extremely convenient to use a partial-concept-id with "models":

[...] if it is a valid expression and its type S models Sentinel<decltype(ranges::begin(E))>.
If T models Iterator and U models ConvertibleTo<iter_difference_t<T>>, [...]

which would be inconsistent with the usage "X, Y, and Z model Flurb<X, Y, Z>". We don't want to require the reader to pattern match against the concept parameters to tell if it's a partial-concept-id.

I now believe we should use "models" as "Args1... model(s) Concept<Args2...>", meaning that Concept<Args1..., Args2...> is satisfied, - including the additional semantic constraints - where <> is only present if Args2... is not empty. For our examples, this would produce "T models Blargh only if [...]", and "X, Y, and Z model Flurb only if [...]".

I'm not a fan of "Flurb<X, Y, Z> is modeled [...]", mostly due to dislike for the passive voice, but I suspect there are or will be occurrences embedded in comma-separated lists that would become incredibly hard to parse using the active voice style. I suggest we prefer "models" to "is modeled" when possible.

I now believe we should use "models" as "Args1... model(s) Concept<Args2...>", meaning that Concept<Args1..., Args2...> is satisfied

Correction: if Args1... contains more than one argument, this usage would be inconsistent with how the core language uses partial-concept-ids, except perhaps when the concept's first parameter is variadic, in which case I (1) don't recall the exact rules, and (2) don't care because I've never seen such a thing in the wild. Use of "models" with a partial-concept-id should be constrained (pun intended) to the case where there is a single argument as in the two examples from P896.

I think that means we're considering constructions from this list:

T models Blargh only if [...]
X models Flurb<Y, Z> only if [...]
X, Y, and Z model Flurb only if [...]

right? I don't like the third one, because it seems to be too similar to the first: it could be read as saying X models Flurb, Y models Flurb, and Z models Flurb only if [...].

Hmm. How about we make it a bit more explicit what we mean, and emphasize the relationship between "models" and constraint satisfaction:

T models Blargh if and only if Blargh<T> is true and [...]
X models Flurb<Y, Z> if and only if Flurb<X, Y, Z> is true and [...]
X, Y, and Z model Flurb if and only if Flurb<X, Y, Z> is true and [...]

That seems to remove any margin for misinterpretation, but we should be consistent: if we define "models" for Flurb<Y, Z>, we should not later use "models" for plain Flurb, and vice versa. (That is, we either consistently present a concept as being a unary concept that might be parameterized, or we consistently present it as being an n-ary unparameterized concept, but we don't mix them for the same concept.)

Does that seem reasonable?

Since some factions want to move away from having a plain concept-id evaluate as a Boolean expression, I'd suggest "...if an d only if Blargh<T> is satisfied and ..." This makes the "models" vs. "satisfies" relationship even clearer. Agreed with the rest.

I'd suggest "...if and only if Blargh<T> is satisfied and ..."

+1. I think this form is clearer even if Blargh<T> continues to be a prvalue bool.

I think that means we're considering constructions from this list:

T models Blargh only if [...]
X models Flurb<Y, Z> only if [...]
X, Y, and Z model Flurb only if [...]

right? I don't like the third one, because it seems to be too similar to the first: it could be read as saying X models Flurb, Y models Flurb, and Z models Flurb only if [...].

I think context should make the meaning apparent. If we're defining template<class T, class, U, class V> concept Flurb, the interpration "X models Flurb, Y models Flurb, and Z models Flurb only if [...]" doesn't work since Flurb needs three arguments.

T models Blargh if and only if Blargh<T> is true and [...]
X models Flurb<Y, Z> if and only if Flurb<X, Y, Z> is true and [...]
X, Y, and Z model Flurb if and only if Flurb<X, Y, Z> is true and [...]

I find these all acceptable.

That is, we either consistently present a concept as being a unary concept that might be parameterized, or we consistently present it as being an n-ary unparameterized concept, but we don't mix them for the same concept.

This restriction would be incredibly problematic for Ranges. We use Sentinel<I> more often than Sentinel<S, I>, but we could not specify the library without the second. That would imply increasing the size of most of the algorithm declarations by rewriting the Sentinel<I> S constrained-parameters as class S and conjoining a Sentinel<S, I> constraint to our already-way-too-long requires-clauses.

Editorial meeting: 24.7.2.3 is the only case with the "models" form of this. Send to LWG.