The usefulness of hg evolve is debatable. It can be useful locally, as much as the reflog can be useful in git, but as soon as you push to the upstream repository, you lose that precious history if you haven't pushed it priorly. Worse yet, the reference to that history is still there in what you pushed, despite being nowhere to be found except in your local clone, making it useless to others.

That's true in case you've created some changesets, played with them locally and pushed them upstream. But, say you've played with changesets already available upstream, the unmodified changesets do not go away.

At RhodeCode (https://rhodecode.com) we believe it's up to a team to decide, which version control better fits their needs and preferences.

Some companies even have Git, Mercurial, and SVN, working all together under centralized repository management.

I, personally, believe it's up to a user to decide which version control system works best for them.

Both git and mercurial can talk to "non-native" remote servers.

IIRC mercurial can talk to subversion and git (with hg-git).

Git can talk to subversion, cvs, perforce, mercurial (there are multiple tools for the latter, and I'm the author of one of them), bzr, and maybe others.

If things don't work smoothly in any of those cross-VCS configurations, my belief is that issues should be filed and fixed.

Agree. However, large enterprises usually have common compliance/access control policies, something not easily implemented across multiple VCS (unless there's a full-fledged internal development team dedicated to that).

Working in a big firm adds overhead, yet has certain benefits (resources, etc.). That's a whole different topic though.