And split off into a second reply:
Covariance of tuple types is cool. The fact that dispatch always goes to a concrete type is cool.
Sometimes (rarely) people want something else, e.g. https://discourse.julialang.org/t/missing-data-and-namedtuple-compatibility/8136/6. Something that would be cool for this are invariant tuples. An Ituple{Union{Int,Missing}, Union{Int,Missing}}would be a concrete type to dispatch on; basically Ituple{A,B} would by syntactic sugar for struct Itup_23456 v1::A v2::B end. This fights the exponential explosion of needed specializations: Pass via Ituples; then your function becomes slower, because it needs all kind of type-dependent branches; but, on the other hand, dispatch into this function, and the amount of codegen becomes faster. As far as I understood the related discussion, named tuples can currently be abused for this. But I feel that this deserves to be a first class feature, and I feel like named tuples want to become covariant in the long run. I apologize if I grossly misunderstood the current state of things, or if I failed at RTFM (e.g. maybe @nospecialize can be be made to do all this, easily).