While I was proud of how I got a break() into the mix, it smells more like a trick than a well-designed component of the tool. As you point out, it should really stop execution of the current sub as well as preventing execution of the fallthrough sub, and I don't think I can make it do that.

If the user had defined a break() sub of his own, it would be unavailable in the switch subs, masked by the one I defined. But outside of that, it would be perfectly functional. If the user wanted to use it in the switch, he'd have to take a reference to it and call that. I thought it was a reasonable compromise, but I think I have a better, break()-less design in mind, now.

In the K&R book on C, the double-edged sword of fallthrough is addressed. Programmers are encouraged to use it only to apply one code block to multiple conditions, rather than to have one code block fall through to another. That is how I plan to make my case statement operate. Suddenly, there's no more need for break().

For the exceptional cases where chaining is desired, I will provide a local $Case::this (or $Case::self, whatever...maybe $Case::chain) variable that the user can use for recursing or chaining cases. So instead of introducing new pseudo-keywords (and the compromises they bring), we get less-cluttered, DWIM normal operation, and a flexible facility for doing tricky things if needed. The features you requested would translate thus:

last	return
next	$Case::chain->('specified term'); return
redo	goto &$Case::chain

I particularly like having an explicit target for fall-through, which specifically addresses the dangers of C-style fall-through. Oh, and I use $_ instead of $_[0] because that's where I think the current term should go.

I don't think I've designed anything impossible. I won't be able to implement it until next week, though.