Using trees for metatagging

Git's object store uses trees mainly to represent a hierarchical filesystem. It occurs to me that you could layer additional hierarchies on top — specifically, you could use it to track subsets of files, i.e. "tagging".

For instance you want some sort of representation for "the set of files that need review". You /could/ create a new tree and reference all files in that set as children. Now if you wanted to find out what to review, you'd list the children of this tree. After reviewing a file, you write a new tree with the set less that file's ref.. Obviously, if you made changes to the file, it should be reconnected to all other trees that referenced it.

I have a couple of questions about this:

1. Does Git provide plumbing for me to find out which trees
   reference a given blob? If not, I will have to iterate all trees
   and record which ones have a given message as a child.

2. Is there a way you can fathom by which unlinking a blob from the
   main hierarchy also causes it to be unlinked from this meta tree
   I am speaking of as well? Similarly, if a blob is rewritten, how
   could I make sure it replaces the old blob in all referencing
   trees?

3. Am I right in assuming that I'd have to track a completely
   seperate ancestry for this tree, that is create e.g. a commit
   object, point refs/metatrees/mytree to it, and reference the tree
   from the commit?

4. Since this hierarchy is not really to be mapped into the
   filesystem, how would one resolve conflicts when merging
   ancestries? Of course it would be nice if I could check out this
   meta tree into the filesystem, make changes, and be assured that
   new blobs replace old blobs in other referencing trees, as per
   (2.), but that's a pipedream maybe.

5. Do you know of similar efforts? Are there must-reads out there,
   apart from the design of Git?

Thank you,