>The VFP B+Tree needs to store both the key value and a 4 byte record pointer to the actual record.

Just to check - I think I have observed earlier, in maybe 2.0 or 2.6, that it used three-byte pointers until some point (merge level 2 or whatever it was called) and then switched to four-byte pointers. Now I see four-byte pointers on even small cdxes. I figure they changed it long ago without notifying me :)

>The c(20) index should require (20+4) * 10000 = 240000, but VFP uses only 167936 bytes. Note that I specifically created those test values in a way to reduce their compressibility. VFP7SP1 is using 317952 bytes for the index, which is actually more than the theoretical min.

I figure this comes from reserved space in each page. This could actually be used to roughly calculate the percentage of this reserved space - since your fields were largely uncompressable, their overall size can be calculated, but only roughly. What I think is inducing an error into this calculation would be the increased number of level 1, level 2 etc nodes which should be there now that it splits pages earlier.

Apart from our .cdx files being bulkier now, I think we've gained some speed and stability.