@tkoeppe, @zygoloid: opinions?

Editorial meeting consensus: First change agreed. Second change: ctors/dtors/conversions etc. talk about members and go to [class.mem]. Initializations, construction/destruction go into [class]. [class.temporary] goes to [basic] (same level as full-expression). Copying/moving and comparisons under [class]. Leave front matter of "special member functions" without subclauses, under [class.mem].
Maybe separate conversion functions (how to declare) from the "conversions" section.
Consider merging declarations and declarators. Move up [namespace.udecl] under "declarations".

[time] should be a top-level clause "Time and date library".

What about filesystem? If [time] qualifies, probably [fs] does too.

@tkoeppe: [filesystems] is 46 pages. That would be a candidate, but it does also fit under [input.output].
Whereas [utilities] became a dump-everything-here location.

I think we should strive to keep the number of (sub)sections reasonable at every level of the hierarchy. The top level is already large, at 33 clauses, but the suggestions above (reducing the core language footprint) will gain us 4 or 5 clauses.
And I would actually consider putting [re] under [strings], both talk about strings (in the sense of character sequences and the operations performed on them).

Napkin math: 1500 pages / 20 top-level clauses = 75 pages per top-level clause.
40 pages is way below that and needs reasoning why it's at the top level.

Additional ideas with some support: Move [re] under [strings], move [localization] under [input.output].

For C++17, there was tentative agreement to move [numeric.ops] under [algorithm], after we had published the final standard (i.e., make the change for C++20). I had been trying to put together a PR for such a change after the post-meeting mailing, but this seems to be the right place to have that conversation too.

Indeed, this was issue #1511

P1076R0 presents the planned sectioning changes and asks for feedback from LWG and CWG.

Most recent update of P1076 is at D1076R1.

I don't know if you want to deal with this as part of the grand reorganization, but I've just noticed a discrepancy in the ordering of the algorithms. In the synopsis, the declarations of the "partitions" (is_partitioned, partition, stable_partition, partition_copy, and partition_point) precede the declarations of the other "Sorting and related operations" (sort, nth_element, etc.) whereas the specifications of the "partitions" are located in [alg.partitions], smack in the middle of [alg.sorting], between [alg.binary.search] and [alg.merge].

Let me know if this doesn't rise to the level of the Grand Reorg, and I'll submit a separate PR to fix it.

@CaseyCarter, please submit a separate issue so that we can discuss this separately.