Bugs with detection of renames that are also overwrites

One can create a rename that also overwrites an existing file, for example 
with ‘git mv -f’:

$ git init
$ seq 100 200 > a; seq 300 400 > b; git add a b
$ git commit -m foo; git tag foo
$ git mv -f a b
$ git commit -m bar; git tag bar

Git does not ordinarily detect this as a rename, even with -M.

$ git diff --stat -M foo bar
 a |  101 ----------------------------------
 b |  202 ++++++++++++++++++++++++++++++++++----------------------------------
 2 files changed, 101 insertions(+), 202 deletions(-)

But it can (sometimes*) be forced to detect the rename with -M -B.  

$ git diff --stat -M -B foo bar
 a => b |    0
 1 files changed, 0 insertions(+), 0 deletions(-)

However, the resulting patch incorrectly omits the deletion of the 
overwritten file!

$ git diff -M -B foo bar

diff --git a/a b/b
similarity index 100%
rename from a
rename to b

Therefore, the patch can’t be applied to its own source tree.

$ git checkout foo
$ git diff -M -B foo bar | git apply
error: b: already exists in working directory
$ git format-patch --stdout -M -B foo..bar | git am
Applying: bar
error: b: already exists in index
Patch failed at 0001 bar
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

If it matters, I’m using Git 1.7.0.

Also, a question: is it possible to get ‘git merge’ to recognize this 
rename?

Anders

(* I say “sometimes” because -B only detects the rewrite if it deems the 
renamed file to be sufficiently different than the overwritten file.  If 
you use 190 and 390 instead of 200 and 400 above, the rewrite and rename 
will not be detected, even though the rename would be detected if it was 
not an overwrite.  This also feels like a bug.)