I believe those have been deprecated in favor of the evolve extension.
Mercurial is my goto for version control. However, in my experience, the information on the ideal tools/extensions is very scattered. The Mercurial book is 10 years old! For example, few mercurial users make use of branches for throwaway work - they use bookmarks. But how is a new user supposed to know that?
All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations, on top of how scattered the documentation is. It is interesting, perhaps how hg has a better UI, but git has always had arguably more consistent documentation.
(Similar too, both hg and git are built as sets of "plugins" to the core CLI but hg requires much more explicit installation and git just bundled a lot of them directly together and implicitly runs anything that even looks close [any script in the PATH that fits git-command may be run for git command], making it less clear which hg commands to use despite the better general UI, and easier to get started in git with a smorgasbord of commands.)
I somewhat remember the Named Branches versus Bookmarks discussion/confusion thing from the last time I attempted to use hg. It sounds unfortunate that it still doesn't seem very well documented or well explained this many years later.
I believe it is bug free, and fit for real world usage, and has been for years. If you read the details, the issue is there is a chance for performance degradation, and they consider that as "backward incompatible".
Watching hg and git grow up and compete as a darcs user was fascinating. Neither hg nor git had the elegance of the darcs UI (and arguably never will due to disparities in the underlying distributed code model), but it was clear from very early on that both hg and git were beating darcs on performance for large, active repositories. (Which was never a problem for a college student working on teams of maybe 1 to 3, but obviously a hard recommendation for the real world.) I experimented some with hg at the time because it had good Windows support, but had no reason to switch from darcs in college.
My first couple of jobs after college had me spending a lot of time in TFVC, and that eventually that lead to a much greater appreciation of git (and pushing teams to migrate from TFVC to git), and by that point TFS had already starting supporting git side-by-side TFVC, though ironically those same teams pushed hard for GitHub Enterprise. (Which does seem to underscore that git and GitHub really were so co-beneficial.)
By that point a lot of what hg had done right the git team was starting to pick up. At the very least, we should remember hg for pushing git to be better.
(As one example, someone else pointed to `git stash` as something that they didn't think hg had, but as I recall `mercurial queues` [MQ] was one of the earliest hg plugins, and MQ influenced the designs of both `git rebase` and `git stash`, and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.)