I have argued for a long time, done experiments, collected data on both real and trivial repositories, and I have convinced hardcore Git fans that explicit is the way to go.
I don't know anything about your experiments, but it would be interesting to see that on real-life repositories, such as the Linux kernel or Git itself. I doubt that it will work any better than what Git does based on heuristic, but it would be interesting to see.
As to your artificial example, it is not convincing, because it is not what you normally have during development, and the conflict is easy to resolve anyway.
We had the freedom to rename or change the files as much as we wanted, and we did so.
Let's suppose, I move a few functions to another file. Now how is your explicit rename/copy tracking is going to help here?
In my experience, moving code around refactoring is much more common than renaming or copying files. With Git, it is easy to find where some function came from. Somehow I have not found similar functionality in Bazaar, but maybe I did not try hard enough to find it.
I don't want my tool to fail just because I am not following best practices.
Git does not fail, it is just that it works better in some cases than in others. Best practices describe how to take most advantage of it. It does not mean that you cannot do in other ways.
but the pieces of the file that changed in both branches get a >>> <<<< conflict marker).
In simple cases, those markers are really useful, but relying on them in complex merges leads to mistakes, because they do not mark all places that has to be changed (regardless whether rename/copy is involved or not). So, much better way to handle complex merges is to use "gitk --merge", where you can see what was changed and why.
Now, for trivial changes, rename heuristic in Git works pretty well. In cases, where you have substantial changes to some files (=>50%), I primary rely on "gitk --merge" anyway, so those markers are not so important. Not to mentioned that in many cases, those markers can be around the wrong lines.
Personally, I don't have much experience with explicit rename tracking (except SVN but it does not do branches well, so it does not count), but accordingly to Linus, explicit rename in BitKeeper caused more confusion than being helpful.
It is entirely possible to apply the same workflow in both tools.
I have not said that is impossible, but it may not be as easy. And this is the reason why people tend to use one tool in one way, and the other in another.
If we speak about Bazaar, a typical approach is to create a feature branch, to do your work on it. When everything is fine and tested to merge it to "trunk". The problem is that intermediate steps may contain mistakes.
One of key features of Git is interactive rebase. It means that you can amend any commit later. You may want to do that due to some mistakes that you did not notice initially, or based on feedback from other developers, or result of testing the same code on another platform. In my experience, it is rare that the initial series of patches is perfect, especially if we speak about not very experience developers or those who work on the code that they do not know well.
Sure, you can use some patch management system instead, but if it is not integrated with your VCS, it is a real pain. But even if it is integrated, it is more complex than you really want in most cases. Obviously, if you maintain some patches on the top of another code, then you need a patch management system. But if you only want to be able to correct your initial series of patches, interactive rebase is much easier to use.
that you can commit part of a changeset without having tested that it compiles
You can always do that with any VCS. The index just gives you some additional flexibility in doing partial commit, but it is up to how you are going to use this feature.
I often find it very useful, because it allows to split unrelated changes. Sometimes, you start to work on something and notice an existing problem, so you want to fix it and continue to work. The fact that any commit can be amended later means that you can test at any time that you like. Often, it makes sense to review your own patches after you have achieved your goal, so you can clean up some steps, improve your comments, etc. When your patches are clean, it is much easier to review them, and good reviewers do not have much time.
automatically committing a merge if it doesn't conflict.
And why is it a problem? There is always "git commit --amend" to correct the last commit. So, to have it automatic is nothing but a bit of convenience. You have merged and tested. If everything is fine, you do not need to do anything. If merge was incorrect, you can amend the merge and re-run the test again.