"For that to make sense": you go too far... People have been writing generic code on Collection for years now. Valid code that does not break when given set or dictionaries, because Set and Dictionary have flawless implementations of the Collection protocol.
And as soon as you make Set a painful container to deal with, people will just dump their contents in arrays, superbly ignore your semantic angst, and write buggy or correct code, as usual.
Soon enough, a proposal for a Set.elements property returning a collection would come. That's unavoidable: people will not find it very funny to copy an Array(set) initializer in all their projects, and others will complain about the memory overhead created by this "convenience" array.
And people would start using the Set.elements collection in ways that make you feel in a bad horror movie again. Your concern can't be satisfied.
I find @Jens' questions much more to the point: the fact that Set adopts Collection makes it painful to extend Collection with useful methods, because they may clash with the semantics of sets.
But there are many ways to answer this potential issue.
For example, the answer to elementsEqual was conditional conformance.
A possible answer to collection.contains(otherCollection) for sets is to make sure that the semantics of this method allow it to be implementable by Set through Set.isSuperSet(of:). All we'd then need would be to make Collection.contains(_:) a customization point. And maybe deprecate Set.isSuperSet(of:) eventually. End of the drama.
There are many answers. I wish they were examined with more scrutiny before we throw away years of work.
Edit: sorry about the redundant Set.elements paragraph above: you did introduce Set.members in your original post.