I think if it was not for the convoluted Revlog [1] format (which makes it impossible to do a clean-room reimplementation of Mercurial Core), we could see a bit more of adoption by having third-party libraries to interface with Hg repositories. It _might_ have been one of the reasons Git, not Mercurial, was added to TFS [2].
>if it was not for the convoluted Revlog [1] format (which makes it impossible to do a clean-room reimplementation of Mercurial Core), we could see a bit more of adoption
Alternatively, we could see a bit more adoption if it were available under a more permissive license than the GPL.
You can theoretically reimplement Git Core by only referencing the documentation, which, according to some sources, does not "infect" the new code with GPL.
could you not have replaced git with hg above, and the argument still holds? Revlog's format itself isn't under copyright (and i doubt it exists, but only with a patent can you stop a _format_ spec from being used). If you wrote a parser for the revlog format, you aren't "infected".
Also, hg plugins are much easier to write (being in python and all), than messing around with git's internals imho (ala, facebook's modification to hg to make it massively scalable https://code.facebook.com/posts/218678814984400/scaling-merc..., which would've been almost impossible in git).
I tried using Mercurial on Kiln for private, personal projects. When I wanted some of those to graduate to public, GitHub projects it was a pain in the ass. So I switched to Git for all Kiln projects. And Kiln even has either/or magic.