This is the type of analysis I always hope for about file systems, but almost never see. Looks like some of these file systems had linked list files, which is an interesting contrast to inode based file systems like the original UFS, or BSD FFS.
I like the OS/8 file allocation scheme: files are always contiguous. Only one growing file can be open for writing and it allocates space out of the contiguous free space (actually it owns all of the free space until the file is closed, where the unused space is then given back). If you run out of disk space, you have to compact the disk, eliminating space taken up by deleted files.
I like it because it's illustrates the surprising fact that you can get away with only one file open for writing for most things.
https://en.wikipedia.org/wiki/CP/M#CP/M_Plus:
“The last 8-bit version of CP/M was version 3, often called CP/M Plus, released in 1983. Its BDOS was designed by Brown. It incorporated the bank switching memory management of MP/M in a single-user single-task operating system compatible with CP/M 2.2 applications”
Note the “single task” part. That excludes a lot from what we nowadays would be included in “most things”. That, I think, is the reason you could get away with that. I also would guess it was more that programmers would either not know what they missed or accepted it as a limitation that kept the OS small.
Compacting/squeezing was only necessary because magnetic disks were contiguous in their nature and had to be erased and rewritten, which was a time consuming (sometimes very time consuming) and potentially dangerous operation leading to a complete data loss if power flickered.
To a certain extent, the compacting is still there and is done in the SSD's (now called «garbage collection»), although it is also transparent to the user and to the operating system.