Your intuition is supported by the current overload-call algorithm, but the distribution is specific to overload resolution. An ordinary generic call solves T against the argument as a whole, so here it can solve T = str | int and the result is consequently list[str | int].

For this finite set of cases, overloads express the correlation:

from collections.abc import Sequence
from typing import overload

@overload
def listify(x: Sequence[str], /) -> list[str]: ...
@overload
def listify(x: Sequence[int], /) -> list[int]: ...

def listify[T](x: Sequence[T], /) -> list[T]:
    return list(x)

With x: Sequence[str] | Sequence[int], neither overload initially accepts the union as a whole. The typing spec's overload algorithm then performs argument type expansion, checks each union member separately, and unions the successful return types. The result should therefore be list[str] | list[int].

There isn't currently a general annotation that says “map this type constructor distributively over every member of an arbitrary union”. If listify also needs to be publicly generic for types beyond these finite cases, adding an unrestricted generic overload as a fallback defeats this particular trick: that overload can accept the original union directly and infer T = str | int. In that case you need either explicit overloads for the domain where the distinction matters, a separate unrestricted generic function, or narrowing at the call site.

And yes, the potential combinatorial growth is handled explicitly in the overload algorithm: expandable arguments are considered one at a time, and their successful return types are combined.