Aha!

Then 'switch_<void>(n)' is a fused function and 'cases' a sequence of
cases (whether implemented with Fusion or not)...

 > The number of cases *can* vary at compile time. I have a guess that
 > we're talking past each other.

Yes, obviously -- I think because of a pair of parentheses. This code

     switch_<result>(n)
     ((
         // ... hand-written cases, note (( ))
     ));

would've told me more easily what you're up to :-).

 >>> For the purpose of clarification, let me call the original
 >>> interface A and my proposal B.
 >>>
 >>> Again:
 >>>
 >>> * Transforming A to B requires minimal amount of coding. The smarts
 >>>    is already in the PP code. The cost is cheap.
 >> The cost is cheap and the effect is destructive :-).
 >
 > Why is it destructive?

We lose the index and the chance to easily use a single function for all
cases.

 > You must be seeing a use-case that I don't.

Yes, see below.

[...]

 >
 > To be honest, I really don't see your point. I still don't see why
 > you'd want to build A on top of B.
 >

1. As a thought experiment to figure out which of the two variants is
the more basic one, and

2. for parameterizing a single function with compile time information
looked up by index (it's quite common and -as you can probably guess-
the index can be very handy inside the metaprogram).

Now that I have figured out that your interface accepts sequences, we
can actually express the transforms between the two:

     A ---> B: function := L(I): functions[I]()
     B ---> A: transform(cases, L(I): make_pair<I>(bind(function,I())))

     // Notation:
     // =========
     // uppercase - types
     // lowercase - objects
     // L(args):  - lambda composition

I don't expect us to a reach consensus, but hopefully we do understand
each other's points now.

Regards,
Tobias