My clients reports similiar bugs as Eric's, despite my app is written in VFP 5.0a.
After a short investigation I've traced two messages in the UT archive reporting similiar bugs (Shihchau Tai 11/11/97 and Matt Slay 13/11/98). All of them stated a problem but weren't solved (or even confirmed as a VFP x.x bug).
Common feature is:
adding records to the table with optimistic row buffering mode on with generating a new_id() as default value, in multiuser enviroment.
Hold on, hold on Eric - I see you talking: "What this has common with my header corruption problem?!". In my opinion these are different shapes of the same VFP bug.
In my app (please don't teach me how to generate an new_id and how to set a lock):

1. User 1 adds a record. The generated id is read from a buffer and used to mark all child records (view or cursor or even a table). The record exists only in RAM of station1, I suppose.

2. User 2 does the same - and has different id and different record (or VFP wants us to think it has).

3. Users issue save command (TRANSACTION, TABLEUPDATE etc.). Effect: all child records from two different parents are assigned to the one of them. Second parent record contains only zeros - even in the "id" field and has no child records.

The app2 thinks it has a unique record with unique id. In effect it has id of record from user1 (how?!!! - the record is only in memory of station1 - adding request happens a long before save attempt). But the corresponding record is added (with zeros).
It sounds like for the moment of adding second record the dbf header is corrupted (or CDX at least). And the first record exists not only in memory for a long time before users try to save (TABLEUPDATE) them both!!!
I haven't sufficient knowledge about VFP internals to solve or even explain the VFP behaviour. But I count on the most brilliant minds reading this on UT.

I hope that me, Eric, Shihchau and Matt are not experiencing collective hallucination...