you can't have all that. not on GIT and not on SVN.
you've already realized that your requirements conflict with each other and even admitted that your current setup does not cover all the situations so you should change the way you're approaching this problem.
instead of demanding certain capabilities from the tool try to explain what are the actual problems that need to be solved and allow people to suggest ways to solve them, chances are those won't be things you've already considered.
I'll try now to answer the problems you've shown on the comments and completely ignore your initial request, I hope it helps more with the actual situation you're in.
we cannot afford a timeline where the commit messages of every (10-15) modules display in the same place
unlike SVN, in GIT you have branches (real branches) and each branch will have its own history so as long as your devs use branches and you merge them instead of using rebase you should be able to isolate each branch log with the appropiate commands, see git log --graph to get the idea.
currently merges are anxiogenic and therefore developers try to avoid merges as often as possible
there's no real solution for this but there's ways to mitigate the problem.
one way is to have several clones of the repo along with the master copy, if your team is about 40 people and you have 10-15 modules then I guess you have small teams there that focus in particular areas/modules; if that's the case then each subteam should have its own clone of the repo and merge locally there before merging back to the master copy.
this approach effectively splits the merge process (and the responsibility) in two phases, one that concerns the changes within the subteam and another that deals with the interaction with the rest of the modules.
But I must keep the use case 4 (move and edit) to give Git a clear lead in the developer eyes and tame that fear of merge
I'll be completely honest, UC#4 is impossible*. particularly on GIT where the mv operation is actually a composition of rm and add.
perhaps if the addition happens before the movement some (d)VCS can figure it out but I don't think that's the case for GIT, even so I think you're taking the wrong way to "tame that fear of merge" let me explain.
* @sleske suggests to check this thread for a way to do UC#4
the reason people fear the merge is because they don't understand it and SVN forces you to merge upstream (that is, on the server) which adds pressure, the problem with your approach is that by trying to help them avoid it you're reinforcing the idea that merges are something obscure and dangerous that should be avoided, don't do that.
if you want them to get over the fear you need to train them so they have the tools to deal with the situation, in other words don't help them avoid the problem force them to solve it, teach them about all the merges and conflict styles, tell them about rerere, even teach them the octopus merge which I've never used but what he hell teach them that too! and then MAKE them practice so it becomes something they know and can handle.
merges in GIT aren't as stressful as with SVN because they're also local so you can do them as many times as you want without fear of screwing other peoiple's environment, you'll only push them once you're absolutely sure they're ok.
that's all for now, if you have additional concerns add a comment and I'll see if I have an idea, good luck!