I don’t agree, based on my current understanding of what type[...] means.
I’ve come to think that type[C] generally means “the type object for class C” and is only really meaningful for classes, which I think is consistent with what Alex suggested was the current state in his Clarifications.
In other words, not only does the current spec say type[int | str] “is a type error”, it actually says that this symbol is undefined, it has no meaning whatsoever.
If we begin allowing forms such as type[int | str], my read is that this is actually a definition of a form that previously had no meaning. There doesn’t exist a class object for int | str, so the existing definition is meaningless here, I think we are effectively defining syntactic sugar.
As a result, I don’t currently agree that “is consistent with” would be better. To say it is consistent is to state a typing rule (i.e. axiom) as if both type[int | str] and type[int] | type[str] were well-defined apriori; such an axiom is nonsense if the LHS is an undefined symbol.
As a result, I would favor “the same as” over “consistent with” but I actually think “is defined to mean” is better.