FWIW, most opinions are that the "or"s (which I added) are incorrect and should be changed to "and"s. I'm not an editor - so I can't click "merge" in any case - but I'd prefer to see a PR with the opposite change.

Me too. I noticed a motion PR using "or" and checked if it should be "and" instead. The majority's preference would have to wait until after its merge.

@zygoloid, this probably needs your opinion.

Maybe take neither option, and replace ", and" with a semicolon and no conjunction.

Editorial meeting: [alg.all.of] p1 construction is no good. The "or" is definitely wrong (who gets to choose?); some sympathy to avoid the "and". Maybe have a period for "returns", semicolon in the other cases. No "or" or "and".

I'm currently preparing this PR to apply those changes. What do you recommend doing in light of P1718?

I'm currently preparing this PR to apply those changes.

Thank you.

What do you recommend doing in light of P1718?

What do you mean? The paper will go forward as-is. The editors likely need to do the merge by hand. So be it.

IIRC, @mclow provides you the sources to ease the merge. With this PR, you'd definitely need to merge by hand.

Questions:

• Should [alg.adjacent.find]'s Complexity: be made into a list with one item per "overloads", like other lists touched in this PR, like in [alg.equal]'s Complexity:? Maybe the converse?
• Should [mismatch]'s 3 Let's be joined into one Let: with 3 items like in [alg.find.end], [alg.equal], [alg.transform]? How about [alg.copy]p14, [alg.move]p11, [alg.remove]p8-9 (there's inconsistency in the ammount of \pnums), [alg.unique] p1 and p6? Maybe the converse?

Limiting the changes to what was approved in the editorial meeting and strictly grammar and whitespace fixes. Expect me bring up the other changes when this is merged.