I know we've had huge problems with this in the past at Apple with people adding, say, NSCoding conformance to a type, and then getting in trouble when a later Apple OS implements NSCoding in a different way. (See "Why you can’t make someone else's class Decodable".) If this restriction is the "stick", the "carrot" might be the thing that gets talked about every now and then: forwarding a protocol to a particular property, to make it easier to make wrapper types (the "newtype" solution in Haskell, as @yxckjhasdkjh pointed out).
To @Jon_Shier's points, I actually do think we need a way to disambiguate members from different modules, but that doesn't fix the conformance issue. For the rest of it, the sticking point is usually the behavior of dynamic casts. If we didn't have to worry about those, this would all be a lot simpler (see the "appendix" section in the original post).