Interesting recovery frustrations

[MR ZenWiz]

For reasons I shan't go into here, I saved my Maverick /boot and /
into spare partitions I have set aside for just this sort of thing and
installed RHEL 5.4 on my workstation.  I battled with it for about a
day and decided to go back to Maverick this morning.

I figured it would be a fairly simple task - restore the /home user
I'd previously saved (no problem there), then boot from the live CD
and restore the boot and root partitions, then grub-install and sail
away.

Not.

The first time after the grub-install the system refused to boot at
all - it came up in grub with no information and minimal facilities,
which I pretty much expected, but not being a grub whiz, I went back
to the live CD and munged around again.  This time I did a grub-setup
and specified the (correct) boot partition to use, and that seemed to
work better - it came up, boot grub, waited for me to select the right
version and then - failed again.  Something about not being able to
find the right /.

Again, not being a mighty grub whiz, I dropped into repair mode,
copied the grub.cfg out of the /boot/grub directory, edited it to use
LABEL=/ instead of the (presumably incorrect) UUID, wrote it back to
the right place and rebooted again.  Yes, I know that isn't the
"right" way to do things, but it works and it beats trying to plow
through the documentation for grub and figure out which file needs
what tweaks when the answer is fairly simple (for me, anyway).

This time it complained that / was not ready and offered me the option
to skip the disk check or go in and modify things manually.

I kind of fumbled around for a while, trying to "recover" /, not
entirely sure what to do, eventually gave up on that and rebooted.
Same things, except this time I told it to skip the disk check, and
voila - everything is copacetic.

Questions that arise from this for me are:

1. First and foremost, why do we have such an unbelievably arcane
method of influencing or controlling the boot process?  There isn't a
single facility to display what grub will do or what its settings are
other than to read the fairly complex set of files used to generate
the grub.cfg file.  Even something as simple as a
grub-show-me-what-the-heck-yo're-going-to-do-on-the-next-boot is not
available.

2. Is there a better way to recover form a situation like this (OS
overwritten intentionally after being backed up, restoring the backup
and not having it work)?  Obviously, not using the same root and boot
partition would have been a better choice, but frankly I wasn't
expecting this much of a headache getting back.

I went through this once before on another machine, and it drove me up
the wall for 2 hours that time, too, except I did something a little
different and the recovery seemed to be a little easier.

Comments?  Thoughts?  Please skip any "don't do that" or "stick with
Lucid" kinds of "I told you so"s - not needed.  I'm looking more for a
better way to preserve and recover in the future should I need (NOT
want) to boot a different OS from the hardware again.

TIA.