I personally think that the core issue is the lack of proper (in the eyes of the drivers on the Model II operating systems, that is) IRQ emulation in the xtrs WD1000 emulation code upon which FreHD is based. The Model II series uses mode 2 interrupts, and the HDC adapters (types 1, 2, and 4) that actually interface to the Model II bus all have Z80 CTC chips on them to generate the mode 2 vector when the WD1000 board (or circuitry on the interface, in the case of the type 4) generates its IRQ. As always, I reserve the right to be wrong, but that is my educated guess, based on Tandy's known reluctance to spend one penny more than absolutely necessary; the Z80 CTC wouldn't be there if no mode 2 interrupts. With FreHD's primary audience being the Model I/III/4 crowd IRQ emulation isn't a big deal, since, to the best of my knowledge, none of the I/III/4 OS hard disk drivers use the IRQ capability, preferring to use programmed I/O. This is why the LS-DOS 6.3 drivers work ok on the Model II without the proper Z80 CTC sitting there.
With xtrs emulating the I/III/4, there wasn't any reason to fully test the WD1000 emulation's IRQ response, even though the DRQ is asserted after a read or a write.
Now, I haven't dug deeply enough in the FreHD code in the PIC to know whether Fred implemented full WD1000 IRQ emulation or not, but this is where I would start looking if I were inclined to spend the time checking. It should be possible to instrument the FreHD code to send debugging information out the serial port, so you could do command traces for debugging purposes.
In a nutshell, it would be easier to modify FreHD to work with the Xenix and TRSDOS drivers than the other way around, since FredHD is fully open-source.