There's a lesson here, too. To unseat git, you need to not just be slightly better than it; you need to have a big use case for many people and be radically better than it in that particular use case. You even can be worse than git in some others as long as you have that radical improvement to build on.

Being merely better isn't enough; see mercurial.

The use case actually has to be important to people in real life, too, not just be something that sounds cool or people might say is important but they don't actually exert any effort towards implementing; see fossil.

The problem is that it's not clear what that will be. It wasn't hard to tell branch merging was a huge weak spot of SVN even if you were close enough to it to not see the forest for the trees. What is git's weak spot? People might jump up to say "interface!" but the reality is, no, it's not; again see mercurial. Talk is cheap and complaints are cheaper but the reality is the community is not switching en masse because of that. Large binary files is certainly a weak spot and I understand there are some commercial solutions for that that edge out git, but that's not going to edge out git in general because the pain isn't enough for most projects, and while git-lfs isn't necessarily the slickest solution ever it's good enough for programming projects. Submodules are awful but it's not clear to me that there is enough pain there to make people switch even if you made that slick as can be. (Plus, if something did start eating git's lunch because of that, there are improvements git can make that would blunt the impact. Git's fundamental model means submodules are always going to be weird but it doesn't have to be as bad as it is. I think backwards compatibility prevents git from fixing the problems but if something was really a threat it could overcome that and they'd be improved.)

I expect to still be using git for many many years yet.