Probably in the situation where the sum types have actual payloads, instead of being simple enums. For example, if it was

    type SHAPE = NONE | SQUARE(w, h INTEGER) | CIRCLE(r INTEGER) | TRIANGLE(a, b, c INTEGER) | BLOB(e SVG_STRING)

In my solution it entails having

    TABLE WithShapeNone(...)
    TABLE WithShapeSquare(..., w, h INTEGER)
    TABLE WithShapeCircle(..., r INTEGER)
    TABLE WithShapeTriangle(..., a, b, c INTEGER)
    TABLE WithShapeBlob(..., e SVG_STRING)

It seems I can't easily generalize your solution, so I won't strawman it.

Then again, I think the proper solution would just be adding the sum types into the system. We could have "+" implemented as a 3-column table too, but why would we?

Your notice of "only values can be parametrized. Identifiers can not" in the sibling comment is exactly what I was trying to express in these threads: the relational model is first-order, not second-order, so while you can theoretically model everything with it (logician have done it), it's ugly and impractical without some extensions. Better types for "ground" values is one such extension.

For one point I do also believe that adding sum types would be great. Even if the only benefit is eliminating 3-value-logic, it is a huge benefit. I also agree that while it can be modeled it is very ugly, though I wouldn't necessarily blame the relational model. The relational model is a modelling tool. The physical implementation doesn't need to be 1 to 1 with the model. Same as you rarely find pure OO or pure FP languages.

Current DBMSs do also have plenty of solutions for the problem of non-homogenous data. Some allow XML and JSON columns on which you can also enforce schemas. SqlServer proposes sparse tables. PostgreSQL has arrays, enums and structs (and arrays of structs) as data types. But I do agree that sum types ammong other things would really be nice.

As for your example I still believe it is incomplete, but I would like to discuss that in a separate thread.

You make a fair point about actual payloads. My example was illustrating a sum type of unit types, an enum.

Do you care to conjure a more complete example of your solution? As @throwaway894345 said, I believe your solution is difficult to consume. I would like an example with something more concrete than MyTable.

A theoretical elegant but currently impossible solution to consume your solution would require FKs pointing to views. A view called Shape that is a Union All (we know there are no common elements) over the 5 WithShape... tables. Other tables would point FKs to the PK of this View. Unfortunately, AFAIK there is no DBMS that supports FKs to Views.

I do believe this is not really what you have in mind and I have a hunch about what you are trying to get at, but I believe the example is incomplete.