My point is these aren't mutually exclusive concepts, they're just different way to identify how a data structure is composed. I can identify a struct by a name, like String, or I can identify a struct based on its contents, like (min: Float, max: Float?), or a mix of the two, e.g. ClosedRange<Int>. Tuples should be the structs that are uniquely identified by their definition; whereas structs have not only a definition, but can be distinguished by their name and relationships, conformances, etc.
I don't think this would be a good idea, I should be able to look at a tuple, and the definition of Hashable, and know it either conforms to Hashable or it definitely does not with no other context. If a tuple is "maybe Hashable/maybe not", that would violate the idea a tuple is uniquely distinguished by its contents (because its behavior would be distinguishable, therefore the tuple is).
Protocols like Equatable, Comparable, and Hashable should be able to be marked as "distributive" so you can tell if a struct is conformant just by looking at it and the types it contains.