Type alias preserving logic defeats complexity reduction mechanisms

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.

Start by running the linked TypeScript Playground reproduction and compare the Ok and Wat declarations, focusing on the type-alias and complexity-reduction behavior. Trace the compiler entry point responsible for checking these intersections and add a regression test showing that identical Node and Node2 types do not produce a complexity error.