This has gone on long enough.  Three points, two of them academic:

1. I've been convinced that, because of the floppy motor bug (which I
wasn't previously aware of), it is pragmatically more useful at the
current time to have shutdown hooks run before the halt message and
keypress.  I'll move the doshutdownhooks() call shortly (after talking
with the i386 port maintainer), or someone else can.

2. I still think the "it should be *down*!" argument is bogus.  "The
machine is halted" does not mean that all the hardware is disabled, or
that the machine's CPU isn't going to run any code (of course it is;
it's going to reboot when you tell it to reboot, after all), but that
no user processes are running.  This holds regardless of whether
you're transferring to a boot monitor or waiting for a keypress.

If shutdown hooks are "a way of massaging the machine so that it
reboots properly," they should happen at reboot time.  Perry's use of
shutdownhooks also encompasses "a way of keeping the machine from
destroying its hardware" (which seems a little bit outlandish until
you know the actual bug), which would indicate that they should be run
shortly after the machine is halted.  Since it isn't currently a
problem to run shutdown hooks before the halt message, we can go with
Perry's view for now.

Relevant trivia: on both Linux and NetBSD/i386 with PCVT, when the
machine says it's halted, you can still switch virtual consoles.

3. thorpej chimed in with cgd that he thought it would be somehow
harder to debug reboot sequences if more code was run after the halt
message, but he didn't address my claim that it would be trivial to
simply add another printf exactly where you want one to be.  Even if
ddb isn't available, I still claim that "this becomes less useful as a
debugging printf" should be completely secondary to any practical
or even aesthetic considerations.