Daniel:  If this bug is truly independent of PulseAudio, then why does renaming /usr/share/sounds/ubuntu/stereo/bell.ogg change the behavior?  If your argument is that libcanberra is looking at that file, then why is it necessary to remove a -PA- cache file to fix the bell after renaming the file back?  Are you saying that libcanberra is dependent upon and/or writing to files that appear to be owned by PA?

Note that I can repeat all these behaviors from either the 32- or 64-bit LiveCD, using its default settings, which I -assume- means it's using metacity and not compiz.  By default, module-x11-bell appears to be commented out, as I said above.  So who exactly is stealing X bell events?  And how do we -stop- it from doing so?

Robert, in response to various items:
(a) The reason you don't seem to need the rmmod/modprobe fandango is that you've been confining your experiments to gnome (or metacity, or whatever).  Try booting in recovery mode and logging into an X-less shell.  Assuming you do -not- have pcspkr blacklisted, then lsmod | grep pcs at that point should show it.  But if you hit rubout at the start of a line in that shell, you'll hear the bell out your line-out, not from the motherboard speaker.  If you rmmod/modprobe, -then- a rubout there will -not- come out of line-out and -will- come out of the motherboard.  Furthermore, if you type xinit (hence getting into X but not gnome/metacity), you get the same behavior (you can also try rebooting and waiting to do the rmmod/modprobe until you xinit if you'd like to reproduce it the same way).  Note that the X bell will have a different pitch than the non-X bell, which has a different pitch than the motherboard bell---three pitches in all.  But if you do the fandango, you'll get the motherboard bell, whether you're in X or not.  [And note -weird- thing below!]
(b) I think you're right that bug #430203, which I cited as the "slow bell", did make it into Karmic---I looked at bell.ogg in Audacity and the entire sample is only 200ms long, and it's got audio for all of it.  But the gnome/metacity bell is still not firing above 1 Hz, so there's a bug/rate-limiter in there -somewhere-.

WEIRD THING #1:  I noticed that, if you're -not- in gnome/metacity (e.g., either directly in an X-less shell, or in the shell that xinit gives you), -and- if you've booted with pcspkr -not- blacklisted (so it's loaded) but have -not- done the rmmod/modprobe fandango (so your bell is still being intercepted and is coming out of line-out instead of the motherboard), THE FIRST BELL AFTER AN INACTIVE PERIOD VANISHES.  In other words, you're sitting at en empty line in the shell.  You hit rubout.  You hear NOTHING.  You wait a couple seconds.  You continue to hear nothing.   You hit rubout again.  NOW you hear a bell!  In fact, I can repeatably cause non-motherboard bell events to VANISH as long as I hit rubout no more frequently than about once every six seconds.  If I hit it more frequently than that, the first one after a long gap vanishes, and the rest of them come through.  [Note that this might be slightly racy---while I was testing, I managed to hear a bell and then -not- hear one from a rubout less than half a second later, but that's rare.]

Note that this obviously-buggy behavior may possibly have influenced my test results, at least---when I was doing prior testing, I didn't hammer on the rubout key or whatever---if I heard no bell the first time, i assumed it was dead, not that I had to try again within six seconds to find out for sure!  Sheesh.

[I believe that if you're actually in gnome/metacity, the inactive-vanishing-bell bug doesn't manifest---I currently have my line-out connected and I'm doing workaround #2, running xkbevd -bg, and I hit rubout on an empty shell line that had been sitting there for ten minutes.  I heard a bloop from line-out and a beep from the motherboard speaker.  Note, however, that if it's been more than a few seconds, the bloop is delayed at least a second compared to the motherboard; if it's within a second or two, the start of the bloop is maybe only 300-500ms behind the start of the motherboard beep.]

WEIRD THING #2:  If you -are- getting the motherboard bell (meaning you've done the fandango), holding down rubout in an X-less shell gives you the bell at what seems to be the key-repeat rate, maybe 10-20Hz.   But if you're in X (e.g., via xinit, not gnome/metacity), holding down rubout gives you a bell that's only running at about 2Hz.  The duty cycle of the X-less bell is close to 100%, but the duty cycle of the X bell is closer to 30-50%.  (They seem to have about the same -duration- when you're just getting one of them at a time, so I guess the X-less bell is interrupting itself when you hold rubout down, possibly so as not to pile up a huge backlog---see below.)

By way of comparison, my 5.04 Hoary machine (yes, that old) gets this right, -even in gnome-:  holding down rubout gives me a 10-20Hz stream of motherboard bells.  So does Breezy.  And this -even- works if I'm ssh'ed to a Karmic machine from Hoary or Breezy and hold down rubout---the Hoary & Breezy machines give me a rapid-fire stream of bells from the shell on the Karmic machine, so it's pretty clearly getting intercepted by the window system under Karmic.

And, of course, if I make the Karmic machine the one with the window system and ssh to one of the older machines, I get the Karmic machine's poor bell handling.

Obtw, one problem with your workaround #2 is that apparently the X bells it plays take a while (maybe I can tighten up their duration, but then an isolated bell is harder to hear).  This means that, unlike the "working" case in older releases, holding down rubout makes it -really easy- to get -way- ahead of the beeper---so a second or two of holding down rubout then barrages you with ten seconds of motherboard beeping as X plays each and every event at full duration.  So this isn't quite a complete workaround compared to the way the bell worked before Karmic broke it.  (Yes, -broke- it---this whole set of behaviors is very clearly a regression.)

My opinion is that this entire codebase has decayed badly and could REALLY use some concentrated attention by someone who knows what they're doing.  We're just flailing here---someone who knows the codebase could probably fix all of these random bugs in short order, if only someone would deem UI regressions from older releases an actual priority.  (Despite its many other advantages, I'm not eager to switch to Karmic given the state of audio here...  I -need- that damned bell to work.)

So far, I'd be happy if we just knew where to point the finger for each of these regressions.  I have yet to hear any component/developer take responsibility.