I think you mean 494h, and that word value is the "number of bytes in buffer".
The IRQ 2 handler calls the "write byte to buffer" subroutine, and it will only call it for one byte of available data.
The "write byte to buffer" subroutine increments 494h each time it is called.
The subroutine that writes the version command with interrupts disabled calls the "write byte to buffer" subroutine for each byte of data it reads until it reads an ACK.
When the version number is checked there is an error condition if 494h is zero because it indicates the buffer is empty.
I don't know about other environments, but in DOSBox the thing that prevents the IRQ 2 handler from executing is the PIT declining to activate IRQ 2 because IRQ 0 is active. I can see this happening easily because I put a log message in DOSBox's PIT code for the specific condition, and that message appears right after I step the POPF that enables interrupts.
You can tell if the subroutine has been called from the IRQ 0 handler by stepping out. It's several levels down in the call stack, but you'll eventually get back to the IRQ 0 handler and its EOI and IRET. Also, if you look at the stack you will see the IRQ 0 handler's return IP of 00C7h followed by the CS.