We've had some disagreement about the behavior of TypeVarTuple substitution related to PEP 646, and the discussion has now spilled around multiple PRs. I'd like to use this issue to come to an agreement so we don't have to chase through so many different places.

Links:
- GH-31021 (merged) implements PEP 646 in typing.py. Matthew initially implemented full TypeVar substitution support, but took it out after I suggested an alternative solution in https://github.com/python/cpython/pull/31021#pullrequestreview-890627941.
- GH-31800 (merged without review) implements TypeVarTuple substitution in Python.
- GH-31828 implements TypeVarTuple substitution in C.
- GH-31844 and GH-31846 add additional test cases.
- GH-31804 (closed) implements my proposed solution.

I'd like to ask that until we come to an agreement we hold off on making any more changes, so we don't have to go back and forth and we ensure that the eventual solution covers all edge cases.

The disagreement is about what to do with TypeVarTuple substitution: the behavior when a generic type is subscripted, like `tuple[*Ts][int, str]`.

There are two possible extreme approaches:
- Implement full substitution support, just as we have it for existing TypeVars. This is complicated because TypeVarTuple makes it much harder to match up the types correctly. However, it is consistent with the behavior for other TypeVar-like objects. My example would turn into GenericAlias(tuple, (int, str)).
- Give up on substitution and just return a new GenericAlias object: GenericAlias(GenericAlias(tuple, Unpack[Ts]), (int, str). This avoids implementing any complex runtime behavior, but it inconsistent with existing behavior and less pretty when you print out the type. I prefer this approach because there's less risk that future enhancements to typing will break it. I also want to explore extending this approach to ParamSpec substitution.