Why an explicit list, rather than keeping it as a range? Like on of these:

Now the tables don't float under this subclause, but rather, are sibling subclauses. Should [utility.requirements.general] be updated to reflect this? Its overview seems to not tell the whole story.

I updated the overview to be exhaustive (using a range of clauses there). I just hadn't got around to it yet.

Thanks for the work on this. First impressions: Overall change looks good to me, but I realized some problems:

I notice that "Result:" is used to specify statements such as "T t;". This is a novelity and [structure.specifications] (3.7) isn't yet ready to handle this situation. I think we need to extend the definition of Result: elements or possibly use a different element (Remarks: ?) for those cases. @jensmaurer What is your preference?

Some requirements (such as "Cpp17CopyConstructible") which extend other requirements (such as "Cpp17MoveConstructible") denoted by "in addition to" need to be fixed to keep the extension character, this information is currently lost, so we need to restore "requirement refinement" effects, most likely by wording of the form as example: "A type T meets the Cpp17CopyConstructible requirement if it meets the Cpp17MoveConstructible requirements and if the [..]"

It seems that wording forms "decltype(a == b) models boolean-testable" are expressed as Mandates: elements, which means that an implementation has to diagnose it. But modeling a concept includes semantic requirements ([res.on.requirements] p1), so would in general require heroic efforts for an implementation to diagnose this. This is better described by a Precondition: or Remarks: element, I guess (I still need to learn the richness of the new elements). We describe here actually the characteristics of the result, that was the reason why it was originally part of the "Return type" column.

Comment: For Cpp17NullablePointer/Cpp17Hash: Don't we want to dismantle Table 29/30 as well into sub-clause [nullablepointer.requirements]/[hash.requirements]? (I assume this is too early to ask, right?)

Thanks, Daniel!, great points!

We'll definitely want to dismantle the other requirement tables, too, but I didn't want to bite off too much, esp. as we're all just learning how to best use these new elements.

I hadn't realized that the Copy* requirements are "in addition to" the respective Move* requirments. That's interesting. I wouldn't mind grouping both under simply "Copy/Move construction" and "Assignment", respectively, but then we'd lose the ability to reference each requirement precisely.

I wouldn't worry to much about the order. My suggested wording form to restore the "in addition to" effects is basically the same approach that we used in the container requirements table, which had the same form and now look as follows
"A type X meets the reversible container requirements if X meets the container requirements, [..]"
I think it is more important to reference them individually.

Ah, that's nice, done!

New snapshot: https://github.com/cplusplus/draft/suites/9952832041/artifacts/482128291

Thanks, the refinement problem seems to be solved here, we still need to fix the Mandates: problem related to boolean-testable. And let's await feedback from @jensmaurer regarding the problem related to the Result: specification of statements.

Ive changed the Mandates to Preconditions for now. One thing we can and should definitely consider whenever we break up requirements tables is that we can split an erstwhile requirement into both a Mandates and a Preconditions bit if that makes sense.

While I in general agree with that split suggestion I guess we need a paper for this with LWG nod on it, because the added Mandates: elements not only impose stronger requirements on implementations but also has effects on any programmer taking advantage of these basic requirements sets as part of their own specification. Contrary to some specific requirements tables (Such as those of the container requirements for example), the basic requirements are not short-cuts for actually concrete component specifications.