This has come up a handful of times on the forum; it's well-understood that folks want this and are aware of the problem, and there's some detailed discussion here: Synthesizing Equatable, Hashable, and Comparable for tuple types
How would this work? Since a nominal type has to have a name, without variadic generics, you'd need a different name for each arity because they have to be distinct types. Would you have Tuple2<A, B>, Tuple3<A, B, C>, and so forth?
That's the thing—Array didn't have Equatable conformance before conditional conformance. There was no workaround; it implemented the == operator but it still could not be used in a context where you needed something that conformed specifically to Equatable, which is what it sounds like you want here. The way tuples support equality today is effectively already how arrays did it before conditional conformance.
There's some debate in the thread I linked about whether making existing non-nominal types like tuples nominal types is the right thing to do. It's also noted in a reply by @Douglas_Gregor that this could be designed and implemented without requiring tuples to become nominal types.
For what it's worth, I did some experimentation a while back in the ProtocolConformance machinery in the compiler to see how much work it would be to fit tuples into the model. It got ugly really fast; that class hierarchy has some pretty strong assumptions that you always have a root nominal conformance that you can work with, and trying to ease that restriction cascaded through a lot of other parts of the implementation. It was unfortunately beyond the knowledge level and bandwidth that I had at the time (and probably have now).
I'd love to see someone figure out how to make it work, though. Fewer special cases in the language == better.