I updated my system this past weekend, with my usual step-by-step
process of doing first /bin and /sbin, rebooting, then doing
everything else.  This resulted in my seeing the "please fsck"
messages once (twice, actually, since I did just the kernel first),
and I forced a reboot so that fsck would clean up (I hadn't actually
known that feature was installed, but its lack has been so glaring for
some time that I figured it out immediately from just the kernel
message :-).  I then wound up replacing /sbin/init (with the domestic
version, should have done that all at once) and rebooting.  fsck
didn't check the filesystem, since it got unmounted cleanly, but there
was a loose inode (the smoking remains of /sbin/init, of course),
which I discovered by doing an fsck by hand.  (Figuring that there WAS
going to be a loose inode.)

Sometime later, in my experimentation with turning my broken cache
back on in the presence of putative cache-flushing code, my system
panic'ed with a "dup alloc" message.  Could it be that the mild
curdling that was left over from the previous reboot caused that,
rather than my cache scrambling DMA?  (There was some other damage on
the filesystems when I rebooted, but that might have been from the
sudeen halt.)

Something else that makes me suspicious of the kernel code that sets
the clean flag: several times, including when I had the unreferenced
inode, when rebooting I got the infinite loop of "vflushbuf: dirty"
messages (I think that's the one, I haven't seen it in a while).  But
after rebooting, fsck announced that the filesystems were all clean.
If the kernel was wedged trying to write something out, why had it
already marked the filesystems clean?  Very strange.