If you have the option, then go with a dedicated tool instead of using the SCM for this. I've written about this on SO, but the argument boils down to coupling, in particular overly tight coupling. Flexible software development is all about avoiding tight coupling unless it's really needed and both Mercurial subrepositories and Git submodules introduce a very tight coupling.
In addition, subrepos/submodules introduce extra complexity in the daily workflow. If people are already familiar with the SCM, then this might be acceptable. But I've seen many organizations where they tries to introduce Mercurial and subrepos at the same time — I consider that a mistake since it just makes everything seem extra complicated.
The Mercurial wiki has a set of recommendations for how subrepos should be used. These include the use of a thin shell repository. This avoids coupling the components together. You can work in either subrepo as needed and push/pull to update them. Once in a while someone (maybe a build engineer, maybe a continuous integration server) will test new configurations of the components. If they pass tests, then a new commit is made in the shell repository so that people have a new base to use for their work.