I go back and forth on what I think is the "best" approach, but I tend to agree that something that emulates at the "floppy cable" level gives the most flexibility and probably would not require much in the way of exotic hardware.
For FPGA systems, you could emulate the VIA and ACIA and built what amounted to a 470 card without too much effort. (Gez, I say that like I actually have even modest VHDL skills...)
From that, it seems reasonable modify the FGPA code to build a "mini floppy controller board" that would interface to the OSI bus on one side and the emulated floppy on the other.
For reads, once you are on a track and have had some "settling time" (which, in this situation, would probably be time to load a buffer), you just keep sending the index pulse, wait a millisecond, and then send the track data. That just plays over an over. (And can even keep going when the "head up" command is sent without too much concern.)
When write is enabled, you send the index pulse and then listen. You could work with the timing, but the easiest way to do it would be to just take the track and sector number and byte count that is in the header of the data you read. You could "enforce" good behavior if you wanted to, but I'm not sure it is worth the trouble.
The only thing bad about that approach is you could not use the "standard" disk emulation formats without some type of conversion. Basically I could see a set of files that were named with the track number and sector. On read, you just play back the track one sector following the other. On write, you capture the sector number and data, and then store it.
Unless you do some type of error checking, someone could probably do things like write 8 sectors of 2K each on a track. I would have to dig into the disassembly, but I don't believe that would really "break" anything in OS65D. (It would also have limited value for the way most users access the disk anyway.)
I don't believe OS65D enforces good behavior, you just ended up with wrap around and overwriting past the index hole if you had a track that was too long. That would corrupt a track, but I don't remember you being stopped from doing that.
The only "trick" is track zero being formatted differently than other tracks. (The header includes the load address followed by the data.) I don't think that exception would be too difficult to handle.
If there is interest in the floppy cable interface instead of serial emulation, I'll have to dig the C4P MF out of storage and get it running...
thanks,
Jim