Bug^Feature? fetch protects only current working tree branch

A `git fetch . origin/master:master` protects the currently checked out branch (HEAD) unless the `-u/--update-head-ok` is supplied. This avoids a mismatch between the index and HEAD. BUT branches which are HEADs in other working trees do not get that care - their state is silently screwed up.

Is this intended behaviour or and just an oversight while implementing `git worktree`?

Steps to reproduce

    # setup

    git clone -b master $SOMETHING xtemp
    cd xtemp
    git reset --hard HEAD~5 # pretend to be back some time
    git worktree add ../xtemp-wt1
    git worktree add ../xtemp-wt2

    # test

    git fetch . origin/master:master
    
        fatal: Refusing to fetch into current branch refs/heads/master  of non-bare repository
        fatal: The remote end hung up unexpectedly

    # OK, current working tree is protected, try another one:

    git fetch . origin/master:xtemp-wt1

        From .
           b4d1278..6e7b60d  origin/master -> xtemp-wt1

    cd ../xtemp-wt1
    git status

        # admire messed up working tree here

    # The protection is really "current working tree", not "first/main working tree"!

    git fetch . origin/master:master

        From .
           b4d1278..6e7b60d  origin/master -> master

    cd ../xtemp
    git status

        # now it's messed up here too

    # Try with "--update-head-ok" but check first.

    cd ../xtemp-wt2

    git fetch . origin/master:xtemp-wt2

        fatal: Refusing to fetch into current branch refs/heads/xtemp-wt2 of non-bare repository
        fatal: The remote end hung up unexpectedly

    git fetch --update-head-ok . origin/master:xtemp-wt2
        
        From .
           b4d1278..6e7b60d  origin/master -> xtemp-wt2