You seem to be missing the following condition from the paper: is_array_v<Container> is false. Are you omitting it because the array overloads would take precedence over this constructor if an array were passed? If so, I think there's a bug since you could be passing an array of incorrect size and this constructor would kick in. The overload for ElementType(*)[N] would be discarded because of a mismatched N, but this one wouldn't (I think).

If I'm right, this would turn what should be a compilation failure into a runtime error with the _LIBCPP_ASSERT(_Extent == _VSTD::size(__c)).

This is commented out because of a clang bug https://bugs.llvm.org/show_bug.cgi?id=38143, where copy constructor will become non-constexpr. Once this fixed, we can un-comment this line (though it should make no difference if it is present or not).

In N4762, they're marked as non-member functions that take span<whatever> by value. This implementation just turns around and calls a member function (with an unpronounceable name) to do the work. The standard never mentions __as_bytes or __as_writeable_bytes.

In my prototype implementation, they were constrained. But LEWG decided not to go there (which is the same approach taken in https://wg21.link/P0805 ). There needs to be another paper written about constraining container comparisons.

It also applies to homogenous comparisons. Consider vector<complex<double>> Two of them can't be compared (less than, etc), because complex<double> doesn't have a operator<

Ugh, actually, I am wrong! The paper is fine and you implemented the paper correctly. The paper says

Remarks: These constructors shall not participate in overload resolution unless:
— `Container` is not a specialization of span,
— `Container` is not a specialization of array,
— `is_array_v<Container>` is `false`,
— `data(cont)` and `size(cont)` are both well-formed, and
— `remove_pointer_t<decltype(data(cont))>(*)[]` is convertible to `ElementType(*)[]`.

since cont has the right constness, the paper properly describes what should happen. My mistake.