OK. What happens if a DMA transfer is busy and a SRST is executed (the only other thing the CPU can do) or a new command is written to the command register?

OK. So each ATA drive has their own IRQ line connected to the cable, doesn't it? How does stuff like drive select affect said routing to the interrupt controller(both PIC and APIC)?

I've just modifed the code to not take both master and slave IRQRQ lines and simply binary OR them for the effective line for the controller to use. It will now use the IRQ line from the selected device only.
Also, drive select(changing bit 4 of the drive/head register) causes the then-selected drive to mask it's IRQRQ line off while the drive select is busy(for 400ns). So when changing between two devices that both have IRQRQ raised, it will lower the IRQRQ output for 400ns, then after the select is finished it will go high again (triggering an IRQ on the PIC or APIC that's connected to the IDE controller).
Would that be correct behaviour?

Edit: I've also just changed the nIEN (requiring it to be cleared for the IRQ line to become high, unless ATAPI) to control the IRQ line directly (becomes a set or tristate(cleared) depending on it). The SRST bit also does the same, but always forced the IRQ line to 0. Those two results are basically ANDed with each other to get a mask on the IRQ line(cleared=IRQ cleared, set=IRQ set/cleared depending on the drive select and drive's own IRQ line), which is combined with the drive select(drive select forces it low as well) and the drive's own IRQ line(which is a flag in the controller that can have two inputs. It can be any combination of being raised by the controller(bit 0 set) and being raised by the DMA controller(bit 2 set). Bit 1 is used as a simple IRQ acnowledge from the interrupt controller (used for debugging purposes(set when the 8259A PIC loads the IRQ into it's IRR register) and might be used for IRQ sharing purposes if implemented later).

The lowering of the IRQ line during drive select will cause pending IRQs from the drive to be raised with edge-triggered interrupt handling. PCI should have no problems with it's changed behaviour(since it's level-triggered, going high afterwards makes no difference).