>>> I think that a minimal improvement would be a clearer error message,
indicating *what* failed and *why*. For instance, Mercurial should print the
name of the subrepo it was trying to update at the time.

Well it already reported 'why' to the best of its abilities. But I suppose
it could be clearer about which subrepo was affected.

>>> The other troubling part of this is that the problem really isn't
fixable without resorting to the debug* commands, so it requires some
wizardry to expunge it.

You should have been able to fix it in the repo of origin without any
special machinations as it should be unaware of any difficulty. Elsewhere,
unless we add an 'hg co --ignore-all-errors', I'm not sure what else we'd
do. Whatever we do, it's not going to be default update behavior for safety
reasons so it's going to be just as obscure as a debug command.

>>> One possibility would be to check the .hgsubstate and the subrepos for
consistency prior to a commit.  If .hgsubstate refers to a nonexistent rev
in a subrepo, it could barf.

But this didn't happen in the case described. What instead happened was that
subrepo listed in .hgsubs didn't correspond with what was present locally.
And that is in fact a perfectly valid and usual state of things (local
changes not present on server) at least up until push happens. And as a
disconnected system, we have no way of knowing whether we're out of sync
until we're asked to push or pull.

And when push happens, we push a subrepo to its default-push destination.
Otherwise we'd be unable to work with anything but canonical sources for
subrepositories. This is probably what actually bit you here. If the
subrepo's default path had been updated, pushing in the parent would have
pushed any outstanding changes to the subrepo.

Again, we can't do much about this if we allow manual editing of .hgsubs OR
subrepo/.hg/hgrc. Changing either independently can get us into this situation.