re reports on experiments
"I'm somewhat surprised"
I'm not surprised. The file system has no memory of what it previously allocated nor any prediction of future intentions. Indeed it has no idea what a particular request will be used for, or even which process it's for, let alone where related extents might be. The allocation is made according to the state of free space and caches at the time of the request. There is no attempt to try to keep files contiguous and given the place of the allocator in the software stack, it wouldn't be feasible to do so for the general case.
On a freshly installed disk, by default, the file system stuff (INDEXF.SYS and friends) will be in the middle of the disk. That gives you two large extents on either side. As you make requests, I believe the allocation algorithms will tend to try to keep the extents even, so the allocations may tend to flip flop between them. This may look like "all over the disk". On the other hand, there are all kinds of other factors which influence where the blocks come from.
Consider, the allocator will do exactly the same thing for a particular sequence of requests, regardless of if the sequence is from one process for one file, or multiple processes writing multiple files.
By definition, you can't "optimize" everything for everyone. So the bottom line is, if you want your files to be contiguous (even though these days it's not entirely clear that it will be any significant benefit), you need to say so up front. Where possible use large initial allocations and large extend sizes to TELL the filesystem your intentions, rather than trying to second guess epiphenomena and emergent behaviour of file system primitives.
A crucible of informative mistakes
