[concepts.equality] p4 "Expressions declared in a requires-expression in this document are required to be equality-preserving, " seems to be the only case of the three mentioned ones where I can't squint the right way, and where a change is obviously normative looking at the wording verbatim.

But it's definitely strange to have such a requirement in a standard library section if it's supposed to apply to all core-language requires-expression s. @zygoloid , can we fix that under the "pellucidly obvious" doctrine? Is it important enough to backport to the C++20 DIS branch?

Para 3 "Expressions required by this document to be equality-preserving are further required to be stable..." is correct as stated. I can't imagine why we would require an expression in the Core clauses to be equality-preserving, but if we did this should apply. Para 4 "Expressions declared in a requires-expression in this document are required to be equality-preserving..." and 5 "This document uses a notational convention to specify which expressions declared in a requires-expression modify which inputs..."are only intended to cover the library clauses. I don't think it's the end of the world if someone is confused into the belief that an expression in a requires-expression in an example in the Core section of the IS is required to be equality-preserving, so I'd say there's no need to port such a change to the C++20 DIS.

I think I can squint at the existing wording the right way: the core language wording itself doesn't declare [sic] any expressions in requires-expressions (at least, outside of examples), it only describes how requires-expressions could constrain expressions within a user program. However, the library wording does specify expressions within requires-expressions, and this rule therefore applies to those. Core language examples are non-normative, so changing whether they're equality-preserving is immaterial.

So I'm OK with fixing this editorially to say that it applies only within the library clauses. I think the intent and meaning is sufficiently clear. And because I think the intent and meaning is sufficiently clear (and that the wording is technically correct already) I'm inclined to not make this change for C++20 post-DIS.