Was seen by mailing list review on 2021-08-30. Attaching a short summary of the comments:

Summary

1. The proposal generally got support.

2. Please make sure the proposal is seen by EWG

3. Make sure the wording avoids p < nullptr comparisons (the current version is probably OK).

4. Suggestion: add comparison with nullptr:

   • For:
     Would like the paper to discuss:
     nullptr < p and p > nullptr, for all non-null pointers pnullptr <= p and p >= nullptr, for all pointers p
     Changing the language semantics so that comparisons of raw-ptrs with pointers of that type and null value, would be defined and make it "smallest" element, will fix the issue (because less<>) need to be compatible with it. The other option would be to impose this as additional requirement on total order produced on ptrs by less<>. But, with the current context, I am opposed to adding operator<=> to nullptr.
     This is why I do not see this as orthogonal to the paper.

   • Against:
     nullptr is not a pointer value; it's just a placeholder that can be converted to a value of pointer type.  At that point,
     you got a null pointer value of a specific type, which can fully participate in comparisons (to the extent such
     comparisons are meaningful). You can only compare pointer values of the same type, and appropriate conversions on the operands ensure a common type is established before performing the comparison.(same for nullopt)
     That was Core DR 583 resolved by N3478
     If you want to write that generic code, use a facility that gives you a well-formed and well-defined ordering of all pointers. The language comparison operator for raw pointers doesn't.

5. Suggestion: make std::less<> well-formed and well-defined for a nullptr

   • For:
     The motivation of the paper is to allow painless comparison and searching against nullptr. The question is how many of operations would be useful (remove, equal_range), and how many of them, may lead to not-portability, due assumption of certain ordering of null wrt not null. And weigh these two, given that there exists a simple alternative, as passing std::equal_to/std::less instead of std::ranges::less,std::ranges::equal to this function.

   • Against:
     For raw pointers, less<> is not well-formed for nullptr and pointers, because there is no implementation-defined strict total order of nullptr and a pointer.
     less<> is not well-formed for nullptr and pointers, because there is no implementation-defined strict total order of nullptr and a pointer. clang+libc++ accepts it because they deliberately hack it to work (here: llvm L11978) and in msvc+stlstl it works because msvc doesn't yet implement the language change that makes comparing a nullptr and a pointer ill-formed.

Outcome

Please provide a new revision addressing topics (4) and (5) above. (to clarify - I'm asking to document the topics and the author's perspective, not necessarily to add the suggestions). 

Closing due to more than 1 year of inactivity. Please re-open if further work is expected.

I do expect to continue working on this sometimes in the next few months. I just need to arrange the time to be able to do so.