The state of affairs with files and file handling is strange.
...Thus, files and folders need to have some sense of logic to them such that if the manager goes away (ie., Drupal, Gallery, the database), the files still make sense.
, but it is related to a storage backend, so I will ignore it for the time being
There are decent file system reflection interfaces in contrib, unfortunately they are not up to speed with update over the web or having revision/version control.
There are file-node/field style modules, but they don't provide decent directory overviews, expected UI, etc...
It is hard to commit to contrib modules for the long term, since you don't know how long they will survive in the wild.
The direction of the fileapi is (IMO) right. The evolution towards different file handling backends is both sensible and good. The distinction in HEAD between upload module and general drupal file db data is a good direction, I hope. The hook file patch idea is very good, hopefully it will get before code freeze.
All of the above do set up a base framework which, while not providing document management, does provide consistent extensible file handling.
When all that is settled we can think about how do we satisfy the various diverse needs - filesystem based directory structure, file dupes handling, revision handling, permissions, webdav, ftp integration, ....
Until then I'm meeting some of my users day to day needs with my docs module. Well, a shamless plug, but I'm not sorry for it :) It is mainly a UI project, not commiting into any of the hard decisions outlined above. That one should be a cleanup the contrib style project, by merging the efforts of a bunch of interested developers.