Correct, that's exactly the same as what I found, and the bug report I filed contains pretty much the same explanation. I suspect the coder(s) of their exception handler functions thought the first 2 parameters should be passed to UnhandledExceptionFilter. Intentional or not however, this doesn't make them correct.
The only reason I think they got away with it is because UnhandledExceptionFilter doesn't tend to use the context, but when it does.. fireworks.
As for "our way around it", I hope it's clear now that this hack/feature would belong in UnhandledExceptionFilter or maybe the function it calls, PrintStackTrace.
I've also noticed the additional debug output you arranged today when the exception code is 0xeedfade. You can't reuse the 0xeedface branch for this, it tends to crash on printing the exception text then. A separate if branch would be needed.
0xeedface was the Delphi 2 exception code, and I suspect the semantics of the ExceptionInformation parameters changed after that (which would explain why they changed the code to 0xeedfade in the first place).
WBR,
Roel Messiant