git-checkout silently throws away the dirty status of index without a warning?

Hi guys,

Correct me if I'm wrong:

    git-checkout saves the changes to index and working-tree, and
tries to apply them to the destined commit.
    If the changes are applicable, then git-checkout the destined
commit and apply the changes.
    Otherwise, git-checkout fails with warnings and leaves the current
status untouched.

If the above correct. Please help me clarify if the following corner case an intended or unexpected behavior.

Setup and git repo with two commits to illustrate the scenario:

    $ git init
    $ echo aaa >> aaa.txt
    $ echo bbb >> bbb.txt
    $ git add .
    $ git commit -a -m commit1

    $ echo bbb >> bbb.txt
    $ echo aaa >> aaa.txt
    $ git commit -a -m commit2

Forge a unclean index with changes that are subset of the destined commit we are about to switching to.

    $ git checkout -b br1
    $ git reset HEAD^
    Unstaged changes after reset:
    M       aaa.txt
    M       bbb.txt

    $ git checkout HEAD aaa.txt
    $ git status --short
    M bbb.txt
    $ git add bbb.txt
    $ git status

    # On branch br1
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       modified:   bbb.txt
    #

    $ git checkout master
    Switched to branch 'master'

git silently switch to master without warning against the index are "RESTORE/RESET" to clean.

    $ git checkout br1
    $ git status
    # On branch br1
    nothing to commit (working directory clean)

Is this an intended behavior? Though the status and changes can be safely restore from the database with some manipulation. But it may become difficult and tedious if the number of involved files are large.

Regards, Roy