"Tagged" sounds like an implementation detail to me (that it has a "tag" internally to tell between types). I suspect they added "type" to "union" to make it clear what is about (about types). The syntax itself has just "union", judging by the document.

UPD. They have this in the FAQ:

  Q: Why are there no tagged unions?
  A: Union structs are both tagged unions and type unions. Under the hood, a union struct is a tagged union, even exposing an enum property that is the tag to enable faster compiler generated code, but in the language it is presented as a type union to allow you to interact with it in familiar ways, like type tests, casts and pattern matching.

I don't think tag is an implementation detail generally, for example:

    enum Option<T> {
        None,
        Some(T),
    }

The tags are "None" and "Some" which are definitely user facing.

But I see what they mean a bit with the C# example:

    union U 
    {
        A(int x, string y);
        B(int z);
        C;
    }

So it seems like "A", "B", and "C" are tags but also their own distinct types, with a implicit conversions between those and the overall union type

Tagged unions are an implementation detail and are often not the optimal way to solve this problem.

Take Option<Infallible>, it's a ZST, not only is there no "tag" there isn't any data at all. In type theory this is fine, we added an empty type to the unit type, we got a unit type.

Because the proposal is about several kinds of unions:

- closed hierarchies of reference types that the compiler will verify at build time

- value types that use compiler tricks to behave like closed hierarchies (tagged unions)

- custom types that can have any implementation but can hook into the same compiler mechanisms to behave like a union of types

- ad-hoc unions of existing types