Comparison between two protocol objects

The issue names no files or tests. Start by reading #439 and #208, then trace the protocol and protocol_view comparison design described here; done means the open semantic, type-identity, mismatch, valueless, conversion, and scope questions have a decided specification.

#439 forwards member comparisons with an operand of another type and rejects any comparison on an interface I with an operand of type I. The idiomatic declaration is therefore free to be given a meaning:

struct I {
  bool operator==(const I&) const = default;
  auto operator<=>(const I&) const = default;
};
protocol<I> p(A{}), q(B{});
p == q;

Open questions:

1. Meaning. Does const I& stand for the conforming type itself? Conformance would then mean C has operator==(const C&) const, and protocol<I> would get operator==(const protocol&) const. Should that apply only to defaulted comparisons, or to user-declared ones as well?
2. Type identity. The thunk must know that both operands hold the same C before it casts. typeid needs RTTI. The vtable address is cheap but not reliably unique across shared libraries.
3. Mismatched types. == can return false. <=> could return partial_ordering::unordered (which rules out strong_ordering on the interface), order by type_index (an unspecified order), or throw as Boost.TypeErasure does. std::polymorphic omits comparison for this reason.
4. Valueless operands. See #208.
5. protocol_view. Does it compare the referenced objects or the pointers? Should mixed protocol/protocol_view comparison be allowed?
6. Conversions between interfaces. What does a comparison that names the conforming type do when a protocol converts to another interface?
7. Scope. Does "own type" stop at comparisons, or extend to members such as void merge(const I&) and I clone() const?

An alternative is a library opt-in (a tag base or trait) in place of rewriting const I&. That works against the design's premise that the interface struct is the whole specification.