overly smart rebase - bug or feature?

Folks,

I have recently hit a behavior which might well be a feature, 
but it was very surprising (in a bad sense) to me.

I was trying to rebase a branch with changes in some file onto a branch
where this file was recently deleted. I would expect rebase to fail and 
suggest me to  resolve conflict manually.
However it somehow succeeded managing to find another file to patch instead 
of the initial one:

] cat git-rebase-bug.sh
#!/bin/sh
git init
# create three files with the same contents
perl -e ' for ($i=0; $i < 10; $i++) { print "$i\n" } ' >Makefile
cp Makefile Makefile1
cp Makefile Makefile2
git add .
git commit -m"created 3 makefiles"
# delete one file
git rm Makefile
git commit -m"deleted 1 makefile"
# go to another branch, one step back
git checkout -b mod HEAD^
# modify contents of the file deleted in master branch
echo "#10" >>Makefile
git add -u
git commit -m"modified 1 makefile"
# now rebase "mod" on top of "master" not expecting it to succeed
git rebase master mod
]

] mkdir git-bug; cd git-bug
] ../git-rebase-bug.sh
....
First, rewinding head to replay your work on top of it...
Applying: modified 1 makefile
error: Makefile: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
]

Now if I look at the rebase result I see that it chose to patch "Makefile2" 
instead of my lovely "Makefile" (why not Makefile1, btw ;) ):

] git log --stat -1 --pretty=oneline
ce0101fc7884bce3eb9724b75d654e7c40abf0fd modified 1 makefile
 Makefile2 |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
]

I has always agreed with the claim that simple but reliable merge
(rebase, whatever) is much better than smartass one smarter than yourself.

And, to be honest, both merge and cherry-pick do not try to play smart:

] git reset --hard mod@{1}
] git checkout master
] git merge mod
CCONFLICT (delete/modify): Makefile deleted in HEAD and modified in mod. Version mod of Makefile left in tree.
Automatic merge failed; fix conflicts and then commit the result.
] git reset --hard
] git cherry-pick mod
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c f782a81' to retain authorship and message.
]

So, why rebase is smarter?

Yeah, and if it matters I tried it on 1.6.0.2 and 1.5.3.8 on Solaris and Linux.

best regards,
  Fedor.
PS I had problems reaching this list, thus ccing Junio explicitly.
I'm not on the list, btw..