I used transplant to transplant two changesets. If the second changeset
produces a rejected chunk, the transplant (a) destroys the correctly
transplanted first revision and (b) leaves the working directory in an
undefined, unusable state and (c) hg transplant -c does no longer work.

I added a zip containing
- reproduce.bat  a self-contained script which creates a sample repo and
issues the commands to reproduce the issue

- the output of reproduce.bat on my machine.

In short, here is what I found out:
The failed chunk causes a
===
transaction abort!
rollback completed
==
which, in turn, deletes the first (correctly transplanted) revision.
Unfortunately, the aborted transplant needs this revision in order to
continue. Moreover, the working dir is based on that revision, and the
working dir is not updated (it is destroyed effectively).
===
warning: ignoring unknown working parent d9cf31280b5c!
abort: no revision checked out
==

EXPECTED BEHAVIOR: I suppose that transplant should never rollback anything
since rollback effectively disables --continue.

The problem occurs using 2.1.1 . I believe it worked before we updated to 2.1.1

It seems as if INDIVIDUAL transplants work, though.

Note that we rely heavily on transplant... it would really be great to get a
bug fix soon. 

Thanks for taking care of mercurial, it is great software!