In my own (toy) language, I have a variant of the SELECT/CASE
construct that addresses the "fall-though" problem in a general way.

The issue is that in some (not many) uses of CASE, it happens that
cases are related to one another in such a way that a small amount
of calculation reduces one or more cases into some other, simpler
case.  The "fall-through" technique is an limited way of trying
to solve the problem.  But, it requires that the simpler case follow
the more complicated case directly, and that there only be one
complicated case that needs to "fall-through".

Knuth (in "Structured Programming with GO TO Statements") shows
a general way of handling this issue using other control constructs.

   do while (j >0 .and. j<done)

      select (j)
      case(1)
         do something
         j = successor_to_case_one
      case(2)
         do something else
         j = successor_to_case_two
      case(...)
         ...
      end select

   end do

Now, each case can "fall-through" to any other case.  Of course,
this can be abused and really be a looping construct.  The intent
is that every case should set J to a larger number, but you could
actually go back.

In my toy language, the above has a compressed syntax:

   select (j)
   case(1)
      do something
   reselect(successor_to_case_one)
   case(2)
      do something else
   reselect(successor_to_case_two)
   ...
   end select

This also could be used as a looping construct (it would be similar
to one given by dijkstra in one of his books).  But it also solved
the "fall-through" problem with complete generality.

(As in Fortran, the SELECT, CASE, and END SELECT statements
can be labeled, as can the new RESELECT - and the labels must match.)

Not that this is really a serious candidate for inclusion in any real
language.  It's more of a case of me analyzing this problem and
trying to find the best solution I can.  Perhaps there are other
possible versions of such a feature that I haven't considered.
In fact, computed-GOTO is not such a bad version of this either.
It's rare enough that you need it, and with the proper commentary
could be quite legible.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare