I will read (and read again) all your message later to understand well but as you seem better understand the case than me you should be right! I was not aware of the 3rd assumption
If I have time (surely not be the case :( ), I will test the scenario I'm thinking about to verify if you managed well this case...
The case is this one :

    1.User gets latest for branch $/dev/  -> Latest changeset on the workspace is C7

    2.Checks out:
    $/dev/File1 last changed at C5
    ....
    3. Modifies File1
    ....
    4. Someone else checkin a modification on File1 -> C8

    5. You shelve your modification on File1
          - Tfs API reports C6 (because that's the last version you have when you shelve + 1) or C9 (because that's the last version of the file when you shelve +1) ?
          - If that's C6, your algorithm is OK because you will create the branch to the good commit.
          - If that's C9, you will create the branch on a commit with a later change on File1 and doing -1 is not the good solution :(

I hope, TFS give C6....


Also the problem is that you only use shelves to exchange changes with other normal users of TFS (not especially git-tfs users), so, I'm not sure that the 3 assumptions can't always be satisfied.