I totally agree that having the compiler provide special-case support making tuples equatable and hashable, would amount to technical debt.
However, allowing for extensions of fixed-arity tuples lies somewhere in the middle between that and variadic generics. I am not familiar with the difficulty of implementing either solution in the Swift compiler so I cannot comment in the cost-value tradeoff.
One relevant question I have though is the following:
How are tuples currently represented? Because, if we can represent tuples as nested structures (e.g., something like
Tuple1<T> = Tuple<T, Nil>,
Tuple2<T, U> = Tuple<T, Tuple<U, Nil>, ... ,
TupleN<H, ...> = Tuple<H, T: Tuple>), then couldn't we support extensions for arbitrary arity tuples without using variadic generics? We would just need a base case extension and an induction-rule extension and we could derive the extension for any arity via induction. How hard would it be to support something like that? That's also how tuples types are represented in Scala 3 (as opposed to the previous manual up-to-22 element tuple types).