More data files / forks

I'm working on a table access method that stores indexes in a structure
that looks like an LSM tree. Changes get written to small segment files,
which then get merged into larger segment files.

It's really tough to manage these files using existing fork/buffer/page
files, because when you delete a large segment it leaves a lot of empty
space. It's a lot easier to write the segments into separate files on disk
and then delete them as needed.

I could do that, but then I lose the advantages of having data in native
Postgres files, including support for buffering and locking.

It's important to have the segments stored contiguously on disk. I've
benchmarked it; it makes a huge performance difference.

Questions:

1. Are there any other disadvantages to storing data in my own files on
disk, instead of in files managed by Postgres?

2. Is it possible to increase the number of forks? I could store each level
of the LSM tree in its own fork very efficiently. Forks could get truncated
as needed. A dozen forks would handle it nicely.