Jake is pointing out that the core OS interrupt handling for known hardware interrupts deals with real hardware (multiple pieces of it), and you$B!G(Bve only focused on the processor.
Now I haven$B!G(Bt dealt directly with an interrupt controller in almost 20 years (sad to say, because I really liked it when I did that sort of thing), but it is a piece of hardware that owns making sure device interrupts get processed, and also typically manages their priority.
There was a thread here a while back in which I participated that began with OP claiming that it was impossible for asynchronous events like interrupts to be processed with absolute reliability. I replied that that is why hardware /software handshakes are used. I believe I avoided going on to say that interrupt controllers are the hardware piece that does this, but that is indeed their purpose in life$B!D(B
Basically, when the processor has $B!H(Bhandled$B!I(B an interrupt, it sends a command /signal $B!H(Bend of interrupt$B!I(B, or EOI to the interrupt controller. This process of the controller getting an interrupt indication from a device, then presenting it the processor in approved fashion, and then presenting the next when the previous one is handled, is the sort of handshake I was alluding to. This level of handshake is in addition to the one you still typically manage where your ISR has to clear a condition in your device, or otherwise notify the device the interrupt is being handled.
In more primitive OS (such as the venerable DOS, and typically still today in most BIOS) each device driver for an interrupting device does this explicitly in its ISR.
But NT streamlined and simplified this by abstracting IRQL, and it always sends the EOI itself in addition to calling the ISR chain for that vector. This makes drivers easier because the OS (typically the HAL) now owns understanding how exactly you do this. In those old glory days, you could spend a fair amount of design time and rework time in a driver if someone changed controllers, or their I/O address, or command/register set, etc. With the HAL, you don$B!G(Bt need to care- usually, as perhaps demonstrated here, you don$B!G(Bt even know it happens.
So the short of it is that you have triggered the interrupt routine for a known hardware interrupt. By this logic, and EOI has to be sent- Jake is pointing out a side effect of your approach that you probably did not consider.
The exact effect this has depends upon details of the controller. Current systems usually use the APIC, which I have not studied in sufficient detail to say I can claim with absolute certainty that it will cause some other interrupt to be missed or improperly handled EVERY time, but I do know that it is a potential and likely problem [it can definitely happen SOME of the time], which is enough for me to agree that this is not a safe way to deal with this problem. Besides, the whole idea is that you only need ONE controller where this screws you for this to be a problem that breaks you mysteriously on some hardware [even the sort of thing where different production dates of the same model or motherboard behave differently, for instance]. I suppose if one is an absolute expert on every interrupt controller model in use or likely to be in use over the lifetime of your driver, you can push the envelope safely, but I’d rather err on the side of safety.
I$B!G(Bm sure Jake and others here have more current and detailed info available wrt the APIC and other current generation controllers, but I can confidently assert for these reasons that the basic problem he has presented is a real, reasonable and valid objection to this approach.