very useful

But FLAC can't know at creation time that the metadata will only ever be edited on a filesystem/OS combo that supports this feature, so it's unlikely to make the assumption that the pre-allocation is not needed.

This is a part of what it means to be too specialised: entirely non-portable, relying on assumptions that can be broken by moving a file even within one system. That doesn't necessarily have to be a bad thing, and it's not that I think this is a *bad* feature, just that in practice it will have to be used transparently and opportunistically as an internal operation, and probably by applications that either don't produce an output file, or already have a final 'rendering' pass or similar, where they can take the opportunity to defragment the result while they're at it.

If it didn't rely on the ability to safely leave small holes in the final files, it would be a lot easier for programs to use the API opportunistically where supported, but since it's not transparent I believe those opportunities will be few and far between.