A type parameter's default may reference an earlier parameter in the same scope — class C[T, S = T], or class C[T, S = list[T]]. When a generic is parametrized and a trailing parameter is filled from its default, the default was inserted without substituting the already-bound parameters, so C[int] produced C[int, T] instead of C[int, int] (and S = list[T] stayed list[T], chained S = T, U = S stayed unbound).

The fix adds _resolve_parameter_defaults, called from both substitution paths (_generic_class_getitem and _GenericAlias._determine_new_args). Once the parameters are bound it substitutes them into any argument that was supplied by a default. Detection is gated on the argument tuple actually growing during __typing_prepare_subst__, so an explicitly-passed argument like C[int, T] is preserved as (int, T) — only genuine defaults are resolved. Nested defaults (S = list[T] → list[int]) and chained defaults are handled.

Verified on a 3.16.0a0 build and against 3.14.6 runtime objects: C[int] goes from (int, T) to (int, int), and the full test_typing suite passes (738 tests) with the added test_typevar_default_referencing_other_typevar, which covers explicit-vs-default arguments, nested and chained defaults, and a concrete-default guard.

• Issue: [PEP 696] default substitution not applied correctly when parametrizing a generic type. #140665