I now think that Gnome, Metacity, or Pulseaudio are implicated.  The hardware and X itself are probably not.  Details:

I think I've managed to pry this bug quite a bit farther open, but it's not quite there yet.  In particular, I -can- get the system bell to work under bare X as any user.  And I can get it to work under the normal window manager, but only as root, and I haven't been able to reproduce the setup, despite installing from the 9.10 image onto a spare disk and starting over.  (Note also that for a while I thought this was an X bug and opened bug #489855, which will give you my entire X configuration; I'll go back and amend that shortly.)

Here's what I've done:

First, I realized I could simplify the situation by booting my original installation in recovery mode, logging in as myself, and doing "xinit".  Assuming I've done the rmmod/modprobe pcspkr step (since it's already out of my blacklist but that's required to work around some sort of ordering bug), then if I rubout on an empty line in the xterm I get from xinit, I -do- get the system beep!  It also works, of course, if I call xkbbeep.  So clearly X itself is capable of beeping the system bell in Karmic, if it's not interfered with.  (Also, xset does change the bell pitch and duration---but the longstanding bug where the first arg [supposedly volume] is incorrectly -also- interpreted as duration is still with us---looks like "xset b vol pitch dur" is interpreted as "xset b dur pitch dur".)

My next move was to exit out of the xterm and do "startx" instead.  In the resulting gnome/metacity/pulseaudio interface (e.g., what I'd get if I'd just done a normal boot), none of the X beeping worked.  Note that I -can- still exercise the hardware beeper either by calling "beep" with no args (which produces a different-sounding beep) or by doing "echo foo | wall" (which produces yet a -third- different beep---that one, I think, is the true default hardware beep which matches what the machine's BIOS produces on boot).

So I logged out of the gnome and then did "sudo bash".  (Yes, this still left my homedir pointing at my default user directory, which I hadn't been thinking about too carefully.  More on that below.)  I tried "xinit" as root and that xterm also worked correctly.  I exited the xterm and tried "startx", which was the very first time root had run gnome.  And -that- UI -does- work---if I start a gnome-terminal, rubout at an empty line beeps, xkbbeep beeps, and ^G in Emacs beeps.  Could this be some sort of permissions problem?  (It continues to work after rebooting---as long as my window system is running as root, things work.  Yuck.)

Note:  I'd run both "gconf-editor" -and- "sudo gconf-editor", both while logged in as me, while trying to debug this over the last few days, and I suspect that the latter may therefore have been altering root's settings.  (I'd been under the impression that gconf-editor required privileges, but I suspect not.)  I have, however, since run gconf-editor as both myself and as root and used the "find" command to find everything that matches the string "bell" in its name or setting, and stepped through them all with lots of downarrows.  I believe that both users' settings are the same in this regard.

Also note:  Every time I startx as root, "xset q" reports my bell percentage as 50%.  Every time I startx as myself (or just boot the machine normally and let it start it), my bell percentage is 0 and I have to reset it.  What's changing this?  Why only for me and not root?

Another note:  Every time I startx as myself (but not as root), I get a notification claiming "You have logged in in a new language.  You can automatically update the names of some standard folders..." etc.  I assume this is because my locale is set differently?  Presumably the normal system startup sets it one way but booting into recovery mode, logging in, and doing startx does something else?  I've never answered the question---just left the window sitting there until I log out or reboot, since I didn't want to side-effect anything.  I haven't compared environment variables between the two, etc.

I then did "adduser test" (since myself and root were the only two users on the machine) and tried to get -that- user to work.  The first thing I discovered (after putting the user in the "audio" and "plugdev" groups so alsamixer could work) was that that user started with its master volume control both down and muted---WTF?  Its bell was also down and muted.  I fixed both.  However, I am unable to get that user's bell to work under gnome (though it does with in a bare xinit).  Oddly, -that- user also won't beep if I do "echo foo | wall"!  (In fact, I was ssh'ed into the machine in a shell that had just been sitting there for hours, and when I typed "echo foo | wall" as the test user, the ssh'd-in machine's bell beeped, but the local bell did not.  That's different behavior from either myself or the root user---both of them will beep the system beeper if I do that, as well as beeping the system beeper of any machine ssh'ed in.  Yet more WTF?)

Since I'd made enough changes in the last week that I was no longer sure exactly what state things were in, I then powered down, disconnected the machine's disk, connected a spare, and installed Karmic from the 9.10 amd64 LiveCD image.  I did -not- take any updates since the CD image.  (The original machine was installed from the 9.10 alternate installer -beta- CD image and then upgraded every day.)

On that test disk, I tried to reproduce my procedure---changing things in alsamixer and gconf-editor, modprobing pcspkr (since I didn't bother to un-blacklist it there), and "xset b 100".  In this setup, I -cannot- get the bell to work if I startx as root!  (I also tried "su - root" to get my homedir right thing time; no apparent difference.)  The bell just seems broken for me and for root in this test install if gnome/metacity/pulse is running---though it continues to work if I just xinit and use it in that xterm.  I still have that test disk, so I can reboot into it if anyone has any suggestions.  I also made a habit of rsyncing either my entire homedir or root's entire homedir into uniquely-named directories (I created /home/backup and stuck 'em there), so I can go back and try to figure out what files each step might have altered; that's impractical in my real setup.

The next obvious thing is to compare settings among the working & nonworking states, BUT there are issues.  In particular, alsamixer seems to be saving its state in ~/.pulse and in binary-only files therein.  Is there a way to make these human-readable?  Haven't done the research yet.  I'm not sure where else things might be saving state; I've been making use of "find . -mmin -5 -ls" and so forth to try to find out.

As always, debugging assistance appreciated.