Also, some firmwares expose funny bugs on that instance. e.g. my old laptop HP Probook 4530s. This handle's GOP instance doesn't cause drawing, when using its Blt() even though the latter returns success. But the drawing appears on the screen after the loader exits to the fw, for short duration before the fw's Boot Manager redraws its own UI. You also can make it stay for longer, just don't turn off the event on the redrawing callback.
To kzinti, I am wondering, what made you include that code into your loader? I am asking because for the vast majority of machines, both VMs and real hardware this no DevicePath instance handle works just as fine as the other one. For me, only for the aforementioned laptop it didn't. I didn't see any hints on this in the spec. Without them this trickery looks like a bitter experience, trial and error. I refused to insert this hack, thinking it's just an oddity of a particular FW on a particular group of one vendor hw. What inspired to you insert it?
Also, interesting to note, that the spec says, all the handles must have Device Path instance installed. This weirdo handle returns EFI_NOT_SUPPORTED btw. even the reference implementation screws the spec up.