Sure! One big reason is that it's consistent with the intended behavior of generic parameters as described by @Douglas_Gregor in this post, which is the only sensible model, AFAICT, for dealing with conflicting conformances in multiple modules. IIUC it is also consistent with implicits in Scala and other precedented language features.
How would you describe a public conformance that relies on non-public names? i.e. in your example Wrapper is internal. How would users of X know when it conforms to Comparable ?
Oh, do you mean, “how would such a conformance be described to users of X's public API?” In the example given, the conformance of X to Comparable is unconditional, so users would see it as a regular conformance to Comparable. If it were a conditional conformance, you still wouldn't be allowed to use private names in the where clause of its conditional conformance, so again, it would be documented in the ordinary way.
Yeah, that's the easy case ;-)
My instinct has been telling me that we could simply take the most-public implied conformance of the ancestor—why force users to disambiguate if we can avoid it?—but I'd like to have a discussion to analyze the implications of a choice like that more carefully. Certainly, forcing explicit disambiguation is a conservative choice; we can always take a less-strict approach later.