I can't quite reproduce your it-must-be-metacity results, because when -I- try compiz, I just lose X bells completely.  BUT---metacity is -definitely- doing something wacky.  Read on.

Starting from metacity, xkbbell (and rubout at an empty shell prompt) "work" in the same not-really-working manner as always.  (And beep also "works", e.g., I hear it on the MB speaker if pcspkr is loaded and line-out otherwise.)

Doing compiz --replace turns out to be a bad idea on my setup---almost all the time, I lose the ability to click on -anything- (including panel objects), I seem to have focus in no window at all (so typein is completely broken), and X logs errors about glibc corruption (double-frees & so forth).  I have the logfiles, but that's some different bug I don't want to get distracted by now.  (It also doesn't start jockey 'cause it's not automatically looking for drivers, etc.)  I have to kill all compiz-related processes (some with -9) to get a window system back, whereupon doing metacity --replace works.  (ssh is unaffected; this seems purely some X death, so I can fix things up via ssh from another machine).

Going to Preferences -> Appearance -> Extra, on the other hand, does start up compiz without dumping backtraces into my .xsession-errors file.

However, having done so, xkbbell (and rubout etc) are silent.  beep still works.

metacity --replace puts metacity back and gives me the same we-snarfed-your-X-bells behavior as always.

Rebooting didn't change this.  (I wondered if I'd screwed up some state trying compiz --replace a couple times and getting those assertion failures, etc, so I tried going back to metacity, then rebooting, then enabling compiz via the Prefs panel.)

Since I'd been poking around in the metacity source, commenting out a thing or two, I figured that maybe my changes caused it to grab something in X and not let go, hence screwing up compiz.  So I reinstalled the virgin package (essentially) via "apt-get source metacity; cd metacity-2.28.0; debuild -rfakeroot binary; cd ..; dpkg -i *.deb; killall metacity" and tried again.  No change.  I also tried rebooting at that point, just in case.  Also no change.  As long as I'm in compiz, no X bell.  Once in metacity, X bell (as in, it's grabbing X bell events and playing bell.ogg at me).

HOWEVER---I have inadvertently found another issue!  I was doing most of my development on this in a root shell in Emacs, ssh'ed in from my stable Hoary (!) system (due to be replaced by Karmic as soon as this bug is squashed).  In that shell, I typed "metacity" at the prompt.

Whoops.

It spit out "Window manager warning: Screen 0 on display "localhost:10.0" already has a window manager; try using the --replace option to replace the current window manager." AND KILLED THE X BELL ON THE HOARY MACHINE.

I can't get it back.  I'll have to boot, or at least restart X, which means the same thing in terms of losing all my state.  I'm pissed off.

I also tried this on a laptop running Dapper.  ssh'ing into the test Karmic system and, as my normal, unprivileged user, trying to run metacity gave me errors, at about 1 Hz until I killed it, saying "Failed to contact configuration server: ..." etc.  sudo bash on the same X connection (hence now in a root shell on the Karmic machine) and metacity stole that machine's X bell, too!  Note at -at no time- was the machine with the actual X server (e.g., the display hardware) running as root; simply running metacity as root on the target (Karmic) system apparently caused it to say something to my local X server that broke the local bell.

Hmm...

(Presumably, there are tools that let one capture every X transaction in both directions, like an X version of ethereal, but I haven't looked for them and don't know what they are.)

P.S.  This bug still claims in its header and window title to be a Pulseaudio bug.  I wonder if that's causing metacity people to ignore it.  I'm tempted at this point to attempt to open this bug upstream, directly at metacity.