I have 3 repositories, each created with the same code base but different enough to warrant different repositories. My "dream" work flow would be to do work in the development repository and then pull these changes into the other repositories. I know I can do this with something like:
hg pull -r X -f repo
but this will give me all changesets up to X. Is it possible to just pull all the changesets from a specific revision or even from a range of revisions?
If you want to grab the contents of certain changesets and apply them to an arbitrary checkout (note: the resulting changesets will be different changesets, even if they make the same changes), take a look at the transplant extension.
There is no good way to cherry pick revisions in mercurial (that's what your proposed workflow is called). There are some not-so-great ways to do it: export+import (or the convenience wrapper around export+import called transplant), but the draw back there is you have the same changeset with different hashes in multiple repositories, with no good way to represent that if/when you try to move changes across again.
Better is to modify your workflow so that when you want to move over a change you're okay with moving over all of its ancestors, and you do this by consciously picking a changeset's ancestors.
For example, if you're fixing a bug that's in the development repository, and all three "other" repositories don't just change the change's parent revision the tip of the development repository. First do a hg update -r THE_REVISION_WHERE_THE_BUG_WAS_ADDED, then fix your bug, and then commit. You'll see a message saying new head created, which is expected.
Now you'd got that fix as a changesets whose only parent is the changeset in which the bug was introduced -- which must exist in the 3 other repositories or they wouldn't have the bug. So now you can pull that new changeset into the "3" other repositories without bringing everything else in development with them. And then you do a quick hg merge in each of those four repositories blending the bug fix into their deployable tip.
Getting a handle of how to structure repositories with common functionality but customizations in each, can be a little tricky, but if you structure things right you can do all of your intra-repo migrations using using push, pull, and merge, and never have to fix a bug twice, have the same code in different changesets, or re-do a repository's customization.
As a note, the bisect command, does a great job of answering the "where was this bug introduced" question before one starts fixing it.