Re: Yeah, no, yeah
Having used 86-DOS and having perused through the 86-DOS documentation, my impression is that 86-DOS was more of a clean sheet implementation than what you imply. What was copied from CP/M was the API, with system calls using pretty much the same function call numbers and registers as CP/M to allow fairly straightforward translation of CP/M assembly source code for Z-80's to 86-DOS assembler. The difference was that the native cal interface was to use INT 21H as opposed to a jump instruction to 00H (memory is fuzzy on the exact address). 86-DOS did have a compatible jump sequence which then called the INT 21H interface.
FCB's were used for API compatibility, but file sizes were known to the individual byte and not to the individual sector. The FAT's borrowed from M$ Disk BASIC were very different from CP/M's file handling. 86-DOS did have a utility "READCPM" specifically for reading CP/M formatted disks.
86-DOS was a bit more UNIX like in the command structure than CP/M, the COPY command worked more like "cp" in UNIX than "PIP" in CP/M. The "CON", "AUX" and "PRN" were treated more like files than in CP/M. COMMAND.COM had a lot more internal commands (e.g. COPY, ERASE, support for .BAT files) than the CP/M's command interpreter.
86-DOS did not freeze when attempting to read/write from an open floppy disk drive.
The assembly code translate utility shipped with 86-DOS was designed for translating Z-80 assembly code to source code for the 86-DOS assembler - which was really fast.
DEBUG.COM was mostly an expansion of the monitor code on EPROM used on SCP computers.
OTOH, I have no doubt that Tim Paterson was using a CP/M machine to bring up 86-DOS, presumably with a version of the 8086 assembler written to run on CP/M.