Basename matching during rename/copy detection

So Govind Salinas has found an interesting case in the rename detection code:

  $ git clone git://repo.or.cz/Widgit.git
  $ git diff -M --raw -r 192e^ 192e | grep .resx
  :100755 000000 4c8ab79... 0000000... D  Form1.resx
  :100755 100755 9e70146... 9e70146... R100       CommitViewer.resx       UI/CommitViewer.resx
  :100755 100755 90929fd... b40ff98... C091       RepoManager.resx        UI/Form1.resx
  :100755 100755 90929fd... 90929fd... C100       PreferencesEditor.resx  UI/PreferencesEditor.resx
  :100755 100755 90929fd... 90929fd... R100       PreferencesEditor.resx  UI/RepoManager.resx
  :100755 100755 90929fd... 8535007... R097       RepoManager.resx        UI/RepoTreeView.resx

In this case several files had identical old images, and some kept that old image during the rename. Unfortunately because of the ordering of the files in the tree Git has decided to "rename" the PreferencesEditor.resx file to UI/RepoManager.resx, rather than renaming RepoManager.resx to UI/RepoManager.resx. Go Git.

I'm wondering if we shouldn't play the game of trying to match delete/add pairs up by not only similarity, but also by path basename. In the case above its exactly what Govind thought should happen; he moved the file from one directory to another, and didn't even change its content during the move. But Git decided "better" to use a totally different file in the "rename".