A look into my twisted mind, and my bizarre design method. To make up for lack of short-term memory, I make design decisions by writing down my train of thought -- otherwise I just go in little circles, constantly coming up with the same problems and solutions. The effect is that of a schizophrenic having an argument with himself, which is probably not too far from the truth. An innovation I used in this one was to use indentation to signify a tangent from the main decision-making process; it turned out to be very useful.

- two types of specificity!
in the filesystem: this rule applies to all files underneath here, they are all in X
    = 1 rule: filesystem claims /x, OR
    = many rulesl: filesystem claims /x/y/z1, /x/y/z2
    (silly! converting rules into lots is dumb)
BUT then you have the possibility of file-not-founds on a valid claim
    ( assuming you just convert the claim and then add the path )
    - sometimes the file isn't there
    BUT then you want to give an earlier doc, not root (right???)
    - yes, you just recurse up the tree
        BUT how does that work for multiple parents?
        - doesn't matter: you're given one path, not many
AND you might have had a valid response from a less-specific DB claimant
    e.g. DB takes /bob/
         filesystem takes some exceptions in /bob/mary/ (jane and jack)
    filesystem would always win for bob/mary/* even though DB has them
        BUT how likely is that scenario?
        - not very... if it's a few exceptions it would be per file
        - if it's lots of info, then DB is unlikely to have it anyway
SO the filesystem doesn't need to make per-file claims
SO how would it resolve two claims for /bob/* from separate locations?
    - using the ordinary rules of precedence over the two
    BUT what the /bob/ versus /bob/mary/* situation with files?
        - well, yeah, you'd end up with a 404
        BUT that's not supposed to happen!
        - true
            SO some kind of feedback is needed when a claim fails
            - that would allow lower-scored claims a shot
            BUT that means our single-winner algorithm is buggered!
            - yep
                SO we need to return a scored array of winners
                SO should this include specificity score?
                    -yes, probably
            AND what about our search algorithm?
            - That was based on specificity winning absolutely
            - Which is no longer the case, so it's buggered.
        SO the search algorithm should return an array of scored matches!
            - how do we score specificity over priority?

RESULT
    New algorithm that attempts all valid claims before failing, in order
    Tweak to make sure results are neither too small nor too large...
    (and perhaps make these configurable)