Type alias preserving logic defeats complexity reduction mechanisms #54146

Playground link with relevant code

💻 Code

// Just a short block to make a union with > 300 unique members
export type Bit = 0 | 1;
export type SyntaxKind = `${Bit}${Bit}${Bit}${Bit}${Bit}${Bit}${Bit}${Bit}${Bit}`
type NodeMaker<T extends SyntaxKind = SyntaxKind> = T extends T ? {kind: T}: never;

type Node = NodeMaker;
type Ok = Node & Node;

type Node2 = NodeMaker;
type Wat = Node & Node2; // fails to recognize Node and Node2 are identical, issues bogus complexity error

🙁 Actual behavior

On the Wat declaration, we issue a complexity error, even though Node and Node2 are identical.

🙂 Expected behavior

No complexity error, like on the Ok line.

The Wat case is actually easy to trigger in real code, as it's what happens in control flow when a type is removed and then readded to the control flow narrowed union - you get the same type, but with no alias information. I bring this up because we trivially trigger this same issue in a handful of places in our own union-ized code base.

Workaround

In type-space, none, sadly (short of eliminating the duplicated types). In expression-space, casting one of the expressions that's lost its' alias back to the aliased form can remove the error, though this feels bad, since the cast isn't well checked.