Thanks for this additional perspective. Do you see this as being a better option than just forbidding that combination (as per my recent post)?
You're welcome and, there are combinations that shouldn't be allowed because they could create lot of confusion. One such would be creating multiple supersets from a root enumeration (a tree). Allowing that would make it quite unclear what enumerations can be treated as supersets and what enumerations are totally different types unrelated to each other even though they share a common ancestor enumeration.
For instance:
TEnumRoot = (a, b, c);
TEnumA(TEnumRoot) = (d, e, f); // a, b, c, d, e, f
TEnumB(TEnumRoot) = (x, y, z); // a, b, c, x, y, z
In that case EnumA and EnumB are supersets of EnumRoot but, they are completely different types (they represent a different set of constants.) It would make things a lot simpler for the compiler and, easier for the programmer to understand, if branches are not allowed (EnumA and EnumB are different branches of EnumRoot.)
IOW, enumeration supersets should be single chain and strictly additive. In the above example, the compiler would report an error when seeing TEnumB because that creates a separate branch, i.e, a completely new type which can be quite confusing for a programmer that needs to maintain that code.
It's part of the job description to find the hair in the soup.
That would lead to the conclusion that bald programmers write better code since there is a lower probability there will be hairs in the soups they make.
And what if TSmallEnum is declared in a different unit, thus can't be changed in any way?
Allowing enumeration supersets to be spread among units is a source of complications but, it is not unreasonable to require that all subsets of the enumeration be declared in the same unit or possibly in the same "type" declaration as is the case for some pointer declarations. In the case of the same unit, I believe OOP already implements such a restriction using visibility modifiers (though not for enumerations.)
Maybe sets would serve you better than enumerations? With sets you can easily do such things.
Can't do it with sets because a set doesn't define constants, it depends on its elements having been previously defined. IOW, a set is always a derived type, it is a set of something and, that something has to be defined first.