I am leaning toward No. I think it's great that you can make your own version! But to me the existing version is much more understandable, because the cases are in the order in which they're tested. That's particularly important in the situation in which the various tests aren't mutually exclusive, and the one that comes first wins. I understand that the "else" case is different because it has to happen last, but that might not be obvious to a user if the else clause isn't syntactically at the end. And if the library has two variants, users will think there has to be a reason; compare the case of
versus
this means do...while loop
Did we witness your transformation just now from Wizard of Oz to Dr. No? 
I agree, by now - better keep the ELSE at the end (like demonstrated in post #17). I’d still much prefer to have the ELSE included as a standard element of the CASES block, instead of the first IF THEN clause, for reasons I worded in post #15.
You have a point. Then why not throw out the “old” CASES block? (assuming existing code using a block that’s no longer part of a library will continue to work, as any library blocks will be saved with the code - is that correct?).
Yes, that's true, unless there's a change to Snap! itself that makes the old library not runnable, as happened when we required manually enabling Javascript every time you load a project.
About building ELSE into the CASES block, I don't feel super strongly about it, but I'm still leaning toward No, for two reasons: (1) It would make users feel that they have to have a default case (as someone commented earlier in this thread), and (2) Changing a library requires changing its documentation, which is a hassle I'd rather avoid unless there's a super compelling reason to change something.
There’s no hurry. You can always reconsider when you’re going to review libraries anyway.
Circumventing the debate in whether the existing (imperative) CASES block should be replaced, I wrote a multi-branch conditional reporter, with built in DEFAULT, recursively implemented:
“Special cases” are to be defined as follows:
Now this works quite well, except for one curious (test) case:
… which reports “0” instead of (the expected) “NaN”.
I wonder why. See the “control” sprite within: Snap! Build Your Own Blocks.
Hmm. In the if/then/else, don't you mean RUN (REPORT VALUE)? The reason you think you don't is that in this particular case the DEFAULT input is a variable, so it gets unringified. Try putting X+1 in that input slot.
All I can think of offhand is that X in the if/report block isn't in the scope of the LET because the recursive call left its scope.
NaN is one of the "falsy" values in JS.
Some variable handling routines (VarFrame [ getVar, addVar])
coerce/fallback to 0 in this case ( source comment "// don't return null" ... ).
I was able to reproduce that. So … my code is OK, it’s a JavaScript peculiarity transpiring in Snap! Would it help if I file a bug report?
It's kind of intended (at least for null ...)
VariableFrame.prototype.getVar @ threads.js
...
return (value === 0 ? 0
: value === false ? false
: value === '' ? ''
: value || 0); // don't return null
How about a PR with the nullish coalescing operator??