Just a quick note that this patterns occurs in other contexts.
I've been thinking of writing a "feedback" package, which would replace the current general-comments and include other types of feedbacks, such as ratings, or any other type of "pick one (or more) from a list of options" type feedback. (Ultimately, this could be extended to do anything survey does - or, obviously, be implemented using survey as some sort of back-end ...).
The UI here would be a link next to the object that says "comment" or "add feedback" or "rate this *object name*".
Another example: I've also been thinking about a list package, which would let users build lists of objects on the site. Sort-of a bookmarks module internal to the site. Think "My favorite books/places to eat/contacts/movies/whatnot", think IMDB movie lists, Amazon shared lists with comments, etc.
The UI here would be a "Add this object to list <dropdown>" widget next to the object.
The current structure would require all packages that want to enable feedback or allow users to add its objects to lists to 'require' the lists and feedback packages, and put the widgets where they want to.
A more sophisticated solution would be to make it optional to install the feedback and lists packages, and the applications know how to check and provide the proper links.
An even more sophisticated solution would be that the links to feedback/add to list automagically show up even in applications that don't know about them, when you install them.
Does this sound related to your thoughts about DAV?
I would tend to opt for the first, very simple solution: file-storage would simply require the DAV package, and if you don't want DAV support, you still have to install the package, but you can disable or not setup the DAV package, and hence not have DAV support.
Does that help any? I'm not sure I understand the details of your problem.
/Lars