The paper was reviewed on LEWG mailing list on 2021-09-13. (D1 with a fix was sent in the mail thread)

Summary

1. Issue: this is a breaking change. (some suggestions to consider as a DR to C++20)
   It's an incremental improvement over the status quo, the breakage cases are more theoretical than real.
   Outcome: It's agreed that the number of breakages is probably low. There were requests for adding a survey to the paper.

2. Issue: concerns regarding increasing subsumption algorithm's complexity
   Suggestion to eliminate the disjunction and instead introduce an atomic constraint for (convertible_to<const T&, common_reference_t<...>> || convertible_to<T&&, common_reference_t<...>>)
   Author: Agreed. I'll revise the paper with that. (fixed at D1)

3. Issue: the change might not be worth our time, since it comes up only in edge case
   Some suggest it's not an edge case (for example: unique_ptr).

4. Issue: it's not true that the common supertype conversion never needs to happen at runtime
   Some designs require monomorphic functions. Relaxing the requirement that the conversion actually exists and can be called at runtime will break anybody using monomorphic callbacks with proxy iterators.

Additional comments on the topic

• There's a discussion on whether we should weaken the requirements (to achieve more "accurate" heuristic).
  Few alternative suggestions (should be proposed on a separate paper):
  • Introduce new customization point, trait as follows: bool enable_three_way_comparable_with, bool enable_equality_comparable_with Then replace the requirements on common_reference_t (existence and meeting concept) with just checking for the corresponding enable.
  • Add a separate weakly_equality_comparable_with, partially_ordered_with
    Regarding equality_comparable_with - most people assume it should work with any two objects which are able to use the operator = between them. That is not the case, and the cases for which there are common references don't seem to be the main cases for which this concept would be useful.
    The types for which weakly_equality_comparable_with is most useful for are those types which have inconsistent operator==(T, U) and operator==(T, T) / operator==(U, U). In this case, the operator==(T, U) can actually be an equality (form an equivalence relation), but this equality is not consistent with operator==(T, T) or operator==(U, U); iterator/sentinel operator== is actually a case of this.
  • Not use common_reference_t, but instead use an alternative which can fall back on common_comparison_type_t or to_common_comparison(T, U)
• Heterogeneous comparison comes up as a topic (additional related comments on the thread: "LEWG(I) Weekly review - P2405R0: nullopt_t and nullptr_t should both have operator and operator==")
• Relevant proposals: 
  • P0805: Comparing Containers.
  • N3351 (search term: "equational").

Outcome

The proposal generally got good support for fixing / addressing the issue.
Relaxing concepts' requirements and the proposed alternatives were subject to a discussion.
Since it is a breaking change (and potential C++20 DR) it should be discussed in LEWG telecon.

Was seen by SG9 (Ranges) on 2021-01-10 (Full Minutes)

Polls

POLL: Forward “D2404R2: Move-only types for equality_comparable_with, totally_ordered_with, and three_way_comparable_with“ to LWEG for C++23

Attendance: 10

Author(s) position: SF

Outcome: Strong Consensus in Favor

Summary

Paper was forwarded to LEWG for C++23. Will be reviewed by LEWG ML review targeting electronic poll.

A Library Evolution motion was made to advance this paper directly to electronic polling on 2022-01-17. The motion passed with 4 +1s.

P2404R1 Move-only types for equality_comparable_with, totally_ordered_with, and three_way_comparable_with (Justin Bassett)

P2404R2 Move-only types for equality_comparable_with, totally_ordered_with, and three_way_comparable_with (Justin Bassett)

2022-01 Library Evolution Electronic Poll Outcomes

Send [P2404R2] (Move-Only Types For equality_comparable_with, totally_ordered_with, And three_way_comparable_with) to Library Working Group for C++23, classified as an improvement of an existing feature ([P0592R4] bucket 2 item)

Strong consensus in favor.

LWG reviewed this today and asked for a few small edits. We'll see it again next week.

LWG reviewed updates and approved 2022-07-08
Notes: https://wiki.edg.com/bin/view/Wg21telecons2022/P2404-20220708

poll: Put P2403r3 into C++23?

poll: Put P2403r3 into C++23?

This is a typo in the minutes, copied here. It should be P2404R3 of course.

P2404R3 Move-only types for equality_comparable_with, totally_ordered_with, and three_way_comparable_with (Justin Bassett)