reassignment of a `TypeAliasType` should not be evaluated as type expression

Unsurpringly, reassigning some generic TypeAliasType named A as B = A is not the same as subscripting it as B = A[Any]:

>>> type A[T] = T | str
>>> B = A
>>> type(A)
<class 'typing.TypeAliasType'>
>>> type(B)
<class 'typing.TypeAliasType'>
>>> A is B
True

Mypy's behavior (on master and 1.18.2) contradicts this:

type A[T] = T | T   # ✔️ true negative
B = A               # ❌ false positive: Missing type parameters for generic type "A"  [type-arg]

reveal_type(A)      # ✔️ mypy: "typing.TypeAliasType",      runtime: "typing.TypeAliasType"
reveal_type(B)      # ❌ mypy: "types.UnionType[Any, Any]", runtime: "typing.TypeAliasType"

https://mypy-play.net/?mypy=latest&python=3.12&flags=strict&gist=962d28cd59eff168c9cd2057e9f18f88

The error at line 2 is only reported in strict mode, so if you don't use that, I can imagine that it can be rather difficult to debug.

I realize that mypy interprets B = A as if it's B: TypeAlias = A, and it's not like there's nothing to be said for that. But I think that it's rather unlikely that a someone using the type keyword would expect that omitting it would result in the exact same behavior.
For _: TypeAlias that's a different story, and is currently working fine IMO; so I'm purely talking about TypeAliasType here. And given the differences in runtime semantics between the two, I think it's fair to treat them differently.

p.s. congratz with the 20k stars!

Riproduci il comportamento segnalato con l'esempio mypy-play collegato e confronta B = A con B = A[Any], includendo le diagnosi in modalità strict e i tipi rivelati. Traccia come vengono interpretate le assegnazioni che coinvolgono un TypeAliasType generico, quindi aggiungi una copertura mirata che dimostri che la riassegnazione conserva l'oggetto alias e non produce un errore per parametri di tipo mancanti.