When the kernel enters the BSOD/crash routine, nothing is guaranteed to be safe. The stuff that was pre-allocated and set aside? Not safe.
Incorrect. Any memory that has been marked as read-only can absolutely be considered safe. Indeed, the STOP condition may have been caused by some process or the kernel attempting to write such memory. So if the OS marks its core memory (code, jump tables etc) as readonly after loading, those jumptables and that code can absolute be assumed to be safe.
How does a CPU "know" where the QR code routines are at? By a jump table full of pointers to locations in RAM
No, initialized pointer to jump table sitting in readonly memory pages.
I have seen computers crash so hard that they could not even spit out their error message and the result of trying was to do some nasty things with the floppy disk controller.
Obviously that can happen. If the graphics card misbehaves, attempts to use the screen could fail miserably. Likewise with disk controllers.
That not the point, though. The point is what *extra* assumptions generating QR codes makes about what components are still safe to use. If QR code generation makes further assumptions, then yes, it could be a problem. But as it stands, the STOP handling code already uses the screen (error message) and disk (dump to pagefile). If coded correctly (engineered for failure) it makes no further assumptions and thus does not increase any risk.
It's like you and GP totally ignore the most basic principles of OS design and common engineering principles. No, I have not seen MS's code and cannot claim that they make no further assumptions about heap, device drivers etc. But cannot the the reverse either. I *assume* that they are more competent than you and GP, however, and make good use of read-only memory.