[Bug?] "git am --abort" loses previous "git add"

Consider this sequence:

    pwd/master$ git add file
    pwd/master$ git am 0001-patch.txt
    Dirty index: cannot apply patches (dirty: file)
    pwd/master|AM$ git status
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       new file:   file
    #
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    #
    #       0001-patch.txt
    pwd/master|AM$ git am --abort
    pwd/master$ git status
    # On branch master
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    #
    #       0001-patch.txt
    #       file

"git am" itself correctly detected that the index is dirty, and refrained
from doing anything (other than creating and leaving .git/rebase-apply).
It carefully kept what you added so far to the index.

But "git am --abort" is broken and loses the added changes from the index.

There probably are two possible fixes (I am not familiar with the --abort
that was bolted on recently, and haven't checked the code).

 - Perhaps when "git am" fails with a dirty index (i.e. not even starting
   to look at the patches and stopping with unapplicable patches), we
   should discard .git/rebase-apply directory so that we do not even have
   to tell users to run "git am --abort";

 - Perhaps "git am --abort" can be told to tell this case from the usual
   "patch in progress" case, and act differently.

My preference obviously would be the latter, as .git/rebase-apply/ could
be the only place that has the patches fed to "git am" from its standard
input.