I've rerun all my tests.  I've attached a table and legends for it, since no doubt it would
otherwise be smashed by the automatic reformatting done by launchpad (is there any way to
turn that off?).

Note that EVERYTHING works fine in Hoary, Dapper, and Breezy.  I did not test 9.04.
But 9.10 has multiple regressions from the behavior in much older releases.

Things that testers/fixers need to keep in mind:
(a) Logging in from usplash/xsplash is DIFFERENT than booting in recovery mode and doing startx!
    I get various diagnostics in my X log and elsewhere doing startx, -and- the behavior is not
    the same---note the recovery-mode section of the attached table and the presence of --/--
    entries there where there are different results via normal boot into GDM.  [Also, I can't
    run alsamixer via startx (it says "alsamixer: function snd_ctl_open failed for default: No
    such file or directory" whereas it works fine in a normal boot -or if I run it in an X-less
    shell in recovery mode.  So clearly doing startx from recovery-mode is different than the
    normal xsplash->gdm boot.  (Also, startx bitches that I've changed my language and prompts
    to rename my homedir the name of one of the directories -inside- it, which I ignore.)
    [And I can't boot in recovery and do "service start gdm" 'cause that requires a sudo, but
    doing it as sudo presumably then runs gdm as root, not me, muddying the water...]
    NOTE ALSO that the VA state ("vanished first bell") is MUCH more common in all the states
    you can get into from startx, as opposed to a normal boot->gdm, where you're only in that
    state before screwing with xkbbell.
(b) You (probably) need to reproduce at least some of this testing on a desktop, where you can
    tell the difference between line-out and the built-in speaker.
(c) See the very first post in this bug for all the other things I had to enable to get bells in
    gnome-terminal to work so this is even possible, e.g., modprobe pcspkr, alsamixer settings,
    maybe xset b, gconf-editor changes, gnome-terminal checkboxes.
(d) Running xkbevd (w/conf file---see "workaround #2" in comment #12) and killing it again is
    NOT THE SAME as never having run it at all during that boot.  Note, for example, the line
    in the direct-boot section, test BL, state 3 (gnome/metacity) vs state 5 (g/m w/xkbevd killed)
    ---{S2/LO,VA} vs {S2/LO} (no VA).  Obviously, some state is being kept around.  I tried this
    -3 times- to make sure I wasn't hallucinating.  Logging out does NOT reset this state.
(e) Each of BL MO NB RM etc tested starting from REBOOT (but not poweroff).  Don't just log out!
    (See point (d) above for why not.)
(f) "beep" (from the "beep" package; not installed by default) and xkbbell are not interchangeable!
    Obvious, but let's be clear here about which is getting called when.
(g) Don't pay all that much attention to my bell-frequency notes; those were guesses and may be
    wrong.  I'll redo them if tracking down who is generating a bell is required and the frequency
    can tell us; if it's not important for fixing these bugs, though, there's no point.

Results, and where I think the blame lies:
(a) METACITY??:  interception of X bells, forcing elaborate and unsatisfactory workarounds.
    This is the #1 issue in this bug report and the most annoying.  REGRESSION.
(b) METACITY:  rate-limiting.  Possibly fixed by bug #430203.  REGRESSION, since the old
    behavior didn't capture the events & hence couldn't rate-limit if it tried.
(c) KERNEL:  un-blacklisting pcspkr insufficient, because then it loads too early and doesn't
    work and must be unloaded and reloaded later by the user.  REGRESSION.  This is probably
    bug #398161, but it's current Importance: Undecided, Assigned to Unassigned, so it surely
    isn't fixed yet.
(d) KERNEL??:  first bell after a pause gets lost in some cases (see table in attachment).  REGRESSION.
    In those cases, for example, doing
       sleep 10;echo a;beep;sleep 10;echo b;beep;sleep 10;echo c;beep;sleep 10;echo d;beep;sleep 10;echo e;beep
    typically beeps ONLY immediately after b and d!  a, c, and e are silent!  (Although
    in at least one case, I got a little blip around d.)  Also, we have these cases:
        sleep 10;beep;beep          [abbreviated single bell]
        sleep 10;beep;sleep 1;beep  [full-length single bell]
    [Note this is "beep" and not "xkbbell", though that's worthwhile to test, too.]

    It all makes me think that something is trying to suppress bells (maybe for rate-limiting?)
    and accidentally suppresses the -first- bell in a sequence (until maybe 1s has passed) and
    then "wakes up", when instead it was supposed to be suppressing the -next- one in the sequence.
    It is PARTICULARLY weird that running xkbevd & killing it again does NOT leave one in the first-
    bell-missing state that one is in before running xkbevd at all, AND that it's MUCH more common
    in startx-from-recovery-mode (where most configurations show the behavior) compared to normal
    boot-into-gdm (where it only shows up on a machine that -has not- run xkbbell since boot).

    NOTE that this is probably NOT a metacity bug, since my testing from a recovery-mode boot
    showed that the vanishing bells happen even if X has never run.

I doubt that the metacity maintainers are reading this bug; I'm considering opening a bug there
and pointing them at this so at least (a) above might get addressed.  If someone else does so
first, post here so we know.

[All of the text above, plus a table of resutls & testing conditions, attached.]