Thanks for the insights!
I think I wasn't clear in my initial post---I'm not booting from a ProFile, or even accessing a ProFile successfully at all. I'm still starting Monitor from Twiggies, and then trying to get it to do anything with the ProFile besides fail to access it. I'd like to have a bootable Monitor ProFile someday, but am not even certain how possible this might be. On the other hand, it may not be too hard, and you might even get my bootloader to do it with some tweaks...
Anyway, your thoughts inspired me to spend several hours this afternoon poring over the listing and experimenting.
1. The first thing I tried is just filling every block on the disk image with an empty p-System disk catalog. Forget interleaving---if it reads anything on the disk, it's going to find that the disk is formatted and has no files on it. Sadly, no joy. The system seems to carry on as if no drive were plugged in---well, except for randomly crashing into MacsBug with an unserviced level 5 interrupt all the time. Not sure why it does this.
2. Now, looking at PDSKRD in the monitor listing ($121C on), it seems like there's a simple disk block checksum mechanism at work during reads. If the read is configured to use disk headers, then the checksum is computed over the entire 532-byte block; otherwise it only does a checksum of the 512 data bytes (and then ignores them; statements $12B8 and $12BC). I think you can bypass the checksum check in "header mode", though, if the seventh byte of the header is positive (statements $12BE and $12C2). So I tried filling every byte of every header with the obviously positive byte $21. Still didn't work.
3. Although LisaEm would surely have been effective for peeking behind the scenes, I decided to investigate the Monitor's disk activity with my hard drive emulator---it's easy to do, since it's a tiny Linux computer, and you can just log in and watch the log messages scroll by. On boot (and when you attempt to mount a ProFile in the System Manager as well), the Monitor attempts to access blocks $000003 and $000007, which, if I've reversed the interleave scheme correctly, means that the Monitor was asking for blocks 7 and then 11... but only if we were in header mode! (Statements $11F0 and $11F4; in "non-header mode", it looks like you don't interleave.
Unfortunately none of these blocks make sense to me. On floppies, block 3 is the second block of the file directory., block 7 is the second block of the first file on the disk, and block 11 is the sixth block of the first file (assuming it extends that far). I'm not sure---maybe the filesystem layout is different in hard drives?
I guess the main thing to figure out then is why it tries to access these blocks. I still haven't been able to pinpoint the spot in the code where it does this. Hmm...