Expand what permit can specify in Sealed Classes

[Suminda Sirinath Salpitikorala Dharmasena]

In light of the comments by Brian & Tagir. May be: `sealed interface
X permit A & B, C & B` will solve the issue if something like this can be
added to Java. This means if B is defined elsewhere A and C must subtype
from X. Both exhaustive checking, extension control and common ancestry is
handled.

As a special case `sealed interface X permit ? & B, C` which can be for any
class or interface subtyping X should be either C or should also subtype B
except for C. ? can become an escape mechanism from the exhaustive checking
which again is explicit opt-out which can be implemented at the JVM
level. `sealed interface X permit ?, B, C` here B, C must descend from X,
while other types can also descend from X. Specifying package or module may
be a more controlled escape mechanism, e.g., `sealed interface X permit ? &
p.or.m & S, B, C` where descents of X in module or package p.or.m must also
be a subtype of S while B and C must descend from X. If ? is left
out `sealed interface X permit p.or.m & S, B, C` or `sealed interface X
permit p.or.m.S, B, C` then only S, B, C can extend X and S, B, C should
extend X and S should be in package or module p.or.m. `sealed interface X
permit p.or.m` means all types in p.or.m, other than X if it is also
defined there, must descent from X. `sealed interface X permit ? &
p.or.m` any type in p.or.m can descend from X.

`sealed interface X permit A & B` means A or B must be defined and it
should be a subtype of X and should extend B or A respectively, which is
verified at compile time. `sealed interface X permit A & B, C & D` means
there should be only 2 subtypes of X which are A and C which extends B and
D or means there should be only 2 subtypes of X which are B and D which
extends A and C.

Maybe there can be `? extends T`, `? super T` and `? extends P super Q ` by
stretching it a bit to limit the classes which escape exhaustive checks.

Also regarding exhaustiveness, there should be a way to specify the classes
without individually naming them (or specifying them in a collective way)
as this list will become inordinately long when mentioning which classes
that can extend a class. One can make a normal class then there is no
control which class may override it. There can be cases where a large
number of classes need to enforce common ancestry or common descendants.

Also, the requirement to be in the same package and the same module is too
stringent as this will prevent proper modularisation by putting the classes
in the most relevant package and module. If all the types are known and
specified then verified at compile-time to check exhaustiveness this will
be sufficient check. At runtime, one can only use what was specified and
verified at compile time.

Maybe