I guess it's acceptable.

Given A, and B < A and C < A types, is a specific B | C union inferred as A with this revert? I believe this was the actual issue we had, right? Inferring Array(A) from [B.new, C.new] is fine, and usually what we want, but a specific [] of B | C could be nice, sometimes.

@ysbaddaden B | C always becomes A. Tracking whether a union was "explicit" (.as) or "implicit" (result of multiple dispatch, an if, etc.) would be far too much complexity and make things very difficult. You either allow B | C and it gets everywhere through implicit semantics, or you always make it A and loose some expressive power.

Sigh. Too bad then.

My personal use case for not merging unions and go to the parent type was having an instance variable with a union type. For example a TypeDeclaration node can only have a Var, InstanceVar or ClassVar as targets, but these get condensed to ASTNode, so when dealing with this we have to do "else raise bug".

I'm thinking whether we can make at least that case work, so when you explicitly define a type declaration like that it keeps it. It would be a special type of union that doesn't go to the parent type when merging it with other types. I'll have to play with this idea, not sure it can work or it's easy.

But then, maybe it'll be too confusing, because sometimes it will get merged, sometimes not, and it will be hard to track. So initially I'd like this to get merged, and then we can think alternative solutions.