Currently, git-annex handles merge conflicts of annexed files well. It makes two differently named versions of the conflicting files (A more descriptive naming scheme including date and commit hash would be nice, but that's a different topic).
However, a conflict of git-tracked files is not resolved, leading to merge conflicts being left open after a git annex sync (thus leaving file contents with the weird merge markers <<<<< etc., breaking file contents.)
Could git annex [resolve]merge be extended to also handle those git conflicts and leave the repo in a clean, merged state after git annex sync|pull|assist?
To not confuse users, it could be opt-in (git annex --set annex.resolvegitmerge true), but maybe the default for git annex assist?
On conflict, it would remove the conflicting file and instead create two versions with suffixes either like annexed files or better the commit hash and/or date.
Submodule conflicts can't be resolved like this, in that case I would use the most recent commit of the two in question.
I think this would violate least surprise. Users expect git-annex to behave like git, and that means merge conflicts like git handles them, when the files are text files tracked by git.
Consider that, if the file is a config file, applying git-annex's resolvemerge to it would make 2 files with different names be in the repository. So the config file would stop taking effect for whatever it was supposed to configure. It would be easy for the user to miss that, because the repository would not be left in a conflicted state.
When you check a file into git rather than git-annex, you are choosing to have git manage that file normally. If you want the git-annex behavior, you can check the file into git-annex.