It's the last point listed in commonly rejected changes, with the comment that it "cannot and should not" (emphasis mine) be supported by the language.
I also found this, which brings up the burden it would have on the type checker.
I also remember a thread that either started off or eventually became about "anonymous enums as duals to tuples" where language team members chimed in about it being infeasible and of questionable use (focusing on what would be available directly on the type, instead of exhaustive switching). Unfortunately I can't find it now.
This could all be out of date. I also remember a time where typed throws seemed definitely out of the question. I'm totally with you that it's a powerful feature that I would use frequently if available, and see it as basically sugar over enums that you'd otherwise have to write yourself. The challenge seems to be specifically about the constraints system. I suppose disjunctions could be roped off from the constraints system but that might be even more confusing (i.e. where T: P suddenly doesn't work because P is a typealias for Q | R). The problem wouldn't exist with sum types that are strictly duals to tuples, but that means we're asking for String | String where it matters whether I picked case 0 or 1, so you're switching on cases, not types (this also means String | Int is a different type than Int | String), and there's no implicit casting. But that still might be better than having to hand-write type-erasing enums.