Pffff me too, Peter. That printed out to 11 pages!!!
I chose to not duplicate all that stuff here < s >.

1) Writing of RLOCK()ed records.
We were talking about non-transaction processing I thought, and in this case (only) I feel that it would be safe for VFP to write such records before they are UNlocked.
HOWEVER, I agree that it doesn't seem to, and that it certainly couldn't in buffered/transactional situations.

2) "Forcing" a re-read.
I suppose that a RLOCK() does force a re-read of data from the disk.
But it is my experience that a simple GO does too (at least on a table opened SHARED).

3) FLUSH command
We really need much more detail as to how this command works - what it really does to what, when, under what circumstances!
I have mentioned this in a thread in the VFP Documentation section here on UT.

4) SET REFRESH
We also need more details of how this works, when, and on which data.

5) VFP locking (and unlock) mechanism
Jim Booth provided some clarification on this and as I understood it. . .
a) Yes, VFP does use an OS (file system?) facility to accomplish this;
b) It is in actuality a 'semaphore' system unique to VFP and consistent across all versions of FP/VFP. Other (application) systems may use the same facility for similar purposes but theirs too would be unique to themselves.
--- It doesn't matter if any record is identified there by its actual physical location or whatever, but only that ALL FP/VFP versions use the EXACT SAME value to refer to the same record and that no two records can have the same value.
--- I liken this to the IBM mainframe's ENQ/DEQ system if you have any familiarity with that.

You newest observations

We have arrived at a point where it is CLEAR that we do not have enough information, at none of the hardware, OS, file system itself or VFP levels, to come to a sensible conclusion.
I endorse your hint that people who have such knowledge would be awfully helpful here and I think that information could be provided that doesn't disclose patented stuff.

At the least it would be most instructive if the Command Reference documentation would note the relationship of each DML command to physical I/O performed.
For instance:
--- In the GO, GOTO, n documentation: This command causes the record on disk to be (re)fetched except when buffering is in effect and that record has already been modified.
--- RLOCK() documentation: This command (i) obtains a fresh copy of the record from disk unless buffering is in effect and that record has already been modified, (ii) keeps the record in storage without re-write until it is unlocked.
--- REPLACE documentation: .....
--- etc. for all I/O commands

I am astounded that your "sniffing" shows that only records are transferred from the file system to VFP (server to workstation) on a read. It would be very useful to learn what is actually read/(re)written on a physical I/O. We assume it is a cluster, but who knows??? Maybe the hardware is now capable of reliably writing only specific bytes.
I am not so sure that "troubleshooting whatever corruption situation will be the vast impossible job" because writing is no doubt different than reading.
As long as VFP properly tracks the records that it has requested, and the actions against them and the additional copies of them that it manages in storage, then it is what it writes that is really of interest. I would guess (what's new by now?!?!) that there is most likely data requested regarding the "lock semaphores" (file system to workstation) before writes are actually specified in order to accomplish the 'merging' that we both talk about.

You are certain - and your description makes me agree - that it is in Novell that the corruption is happening in your observations of THIS problem. The only sensitivity that comes to mind as relates to your problem is when a VFP record itself EXACTLY fits the Novell cluster and the EOF marker must go to the next cluster. Yet if that was a problem it would occur every "n" cases in any file (depending on actaul metrics) and then only if clusters are always filled to the maximum.

I take it that there is no commonality of HD types (brand and size and on-board cache) or HD adapter brand/model.

good luck my friend