Well, I cannot guarantee it will _always_ be eliminated, since I too
don't really know when generated bytecode can (currently) end in
non-return.  However, if before it ended in non-return, that non-return
must have been unreachable, obviously (else code flow would fall off of
the valid bytecode string).  So, there is pretty good chance that this
patch will remove both the unreachable code and the fake return byte. 
In the worst case, we increase bytecode length by 1 byte, but we always
enable peephole optimizer, which can be expected to give a much more
significant gain.

As your unit tests suggest, the patch doesn't always remove unreachable
code, because some opcodes after which this can be done are already
handled differently.  Also, there might in theory be some false block
boundaries (e.g. a jump from unreachable code to another piece of such
code).

BTW, I think that just removing #if 0'd block is not correct.  I propose
to convert it to a comment then, just to explain that there are more
opcodes after which we can expect unreachable code and don't check only
because it'd give duplicate case labels.  Maybe some goto magic can
handle them, don't have sources here.