I've done a bit more investigation here and found two more things:
Lock promotion doesn't work - i.e. Unix.(lockf fd F_RLOCK 0; lockf fd F_LOCK 0) will block
Blocking out other file handles within the same thread/process is the intended behaviour of the LockFile Windows API call
I can see how the Unix module could work around problem 1 (it's just yet another instance of needing to add information to the fd structure!), but I can't see an easy way to work around the other problem without having to track all open file descriptors and re-map them.
Clearly, POSIX and Win32 give different semantics to file locks. I think it is hopeless to commit on one semantics and emulate it on the other OS (or one both): this sounds technically very difficult, and moreover it's not obvious to me which semantics is the right one! My proposal is just to document the differences in behavior.