Turns out to be csw gtk regression. This should fix it:

diff --git a/gdk/gdkwindow.c b/gdk/gdkwindow.c
index fa8e63c..ec9aa56 100644
--- a/gdk/gdkwindow.c
+++ b/gdk/gdkwindow.c
@@ -8590,7 +8590,7 @@ gdk_window_beep (GdkWindow *window)
   toplevel = get_event_toplevel (window);
   display = gdk_drawable_get_display (GDK_DRAWABLE (window));
 
-  if (toplevel && gdk_window_is_offscreen ((GdkWindowObject *)toplevel))
+  if (toplevel && !gdk_window_is_offscreen ((GdkWindowObject *)toplevel))
     _gdk_windowing_window_beep (toplevel);
   else
     gdk_display_beep (display);

Fixed upstream, will be in the next GTK+ release

The bell is still not working, so should not the bug stay open until the fix really hits rawhide?

Hmm, seems like XBell() is broken in current X. Replacing XBell(dpy, 0) by XkbBell(dpy, None, 0, None) fixes this. I'll commit this workaround, and leave it to the X guys to fix XBell.

Thanks for the workaround. In rawhide, the alert sound now works in gnome-terminal, but only if metacity is used. With compiz, there is no alert sound (see also bug 498594).

In F11, the alert sound is libcanberra-driven when using metacity and a PC speaker beep when using compiz. However, the following issue appears and is always reproducible on my system: if I 

1. reboot
2. log in
3. try triggering an alert sound by pressing 'Left' at the gnome-terminal prompt

then no alert sound is produced. With metacity, the alert sound starts working at the second or third try, with compiz, the alert sound just never works. However, if I

1. reboot
2. log in
3. open pavucontrol
4. try triggering an alert sound by pressing 'Left' at the gnome-terminal prompt

then the alert sound is produced as expected, both with metacity and with compiz.

This is with 
xorg-x11-server-Xorg-1.6.1.901-1.fc11.x86_64
gtk2-2.16.5-1.fc11.x86_64
metacity-2.26.0-1.fc11.x86_64
compiz-0.7.8-19.fc11.x86_64

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I no longer have F11 installed, so I am not able to verify whether the behavior I described in comment #5 still happens. In F12, the bell works as expected.

I am not able to provide the information requested. However, if comment #4 is still valid, XBell() is still broken, and the bug should stay open and be retargeted to rawhide.

I have to correct my comment #8. In F12, the bell works as expected, but only in newly created accounts.

I replaced F11 with F12 and kept my /home partition. In my main user account that was created long before the new installation, triggering an alert sound in the F12 gnome-terminal (e.g. by pressing 'Left' at the prompt) results in silence.

I am now clearing the NEEDINFO flag. I hope this is OK.

XBell() still seems to be broken in F12 (and XKbBell doesn't seem to obey the "xset b" setting).  This means that traditional X apps such as xterm and xbiff can't beep.

...nor can Emacs beep, which for me elevates this bug from "this is a minor annoyance" to "OH NOES THIS IS THE MOST ANNOYING BUG EVER!!!1"

But seriously, for people who rely on the beep for feedback, having it suddenly taken away is *extremely* irritating.

And the beep is still broken as of xorg-x11-server-Xorg-1.7.1-9.fc12 (the latest available in updates[-testing]).

Also, bug 542521 might be a dupe...

*** Bug 542521 has been marked as a duplicate of this bug. ***

This is still a problem with an up-to-date F12 system.  It appears that F11 broke getting a beep from the PC speaker, and F12 "fixed" that by breaking getting a bell sound at all from standard X programs like xterm.

Adding reference to an upstreams freedesktop bugzilla.  A fix was applied a week ago it seems.

This has been fixed for F12 for several months now, so someone should probably close this with CLOSED/CURRENTRELEASE...

Really?  Launching 'xterm +vb', I still don't get a bell.  Is there something else I need to do?

I must be missing something too, as it didn't beep for me on Fedora 12 + an xorg update, and now it doesn't beep for me on Fedora 13 release + updates.

After upgrading to xorg-x11-server-Xorg-1.8.0-12.fc13.x86_64 I now got the bell back.  Since this was reported on F12, and I don't know about the latest updates there, I won't close this issue.  But it seems to be fixed in F13, at least for me.

OK, my mistake - it is beeping for me on Fedora 13; it's just that the pcspkr kernel module is back to not being loaded by default.

*However*, the beep is no longer able to be controlled by "xset b" (which prior to F12 it was).  Do I have to open a new bug for this?...

Is this related to the "bell is broken" issue in F11, F12, and now, F13 that occurs when running KDE or Xfce desktop?  Gnome desktop doesn't seem to exhibit the problem.  But, neither KDE nor Xfce will produce sound when the bell event is generated in a terminal (echo ^G, xkbbell, etc) or xbiff and, I assume other (legacy?) applications.

The part of this bug that sounds promising is that XBell() was damaged, but I've tried xorg-x11-server-Xorg-1.8.0-12.fc13.i686 in F13 and the problem persists.

Should I open a new bug for this?

F13: I get bells via the sound card but not via the pcspkr, even if the module is loaded.  It may be this is being eaten by metacity or similar.

This (extremely lengthy) Ubuntu bug seems related, with the proposed patch particularly relevant to Ian Collier's issue in comment 20 - https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/486154

Yes, GNOME seems to eat the pcspkr beep by default.

Wow, that's a bug report and a half... sadly the patch isn't relevant to me as I'm not running Metacity (or in fact any other piece of GNOME).  There's an implication in there that "xset b 0" turns the bell off for the people testing in Ubuntu.  It does not do that for me in Fedora (xset b is completely ignored).

This bug is just about the XBell() events not getting through; the pcspkr issue is a separate problem (see BZ 516816 - the pulseaudio author decided that you shouldn't get a pcspkr beep anymore).

Okay, I'm fine with not getting pcspkr noise.  I miss it, too, but I'm willing to live without it, provided *some* audible alert occurs when the bell/beep event occurs...but I'm not even getting that.  If I still have the problem in F13 w/ xorg server pkg v1.8.0-12.fc13, does that mean this is a different bug?

It think so.  I'll open a new (old) bug report.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Hooray!  I upgraded to F14 and now "xset b" works again*.  This bug is fixed as far as I'm concerned.  (However, I'm not running pulseaudio.)

[* the first parameter seems to affect duration rather than volume, but maybe that was always the case?]

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.