No, it doesn't totally defeat the usefulness of focus follows mouse.  For a
certain smaller subset of users, it totally destroys their interaction and
placement model, but for the majority of focus follows mouse users this is
actually the correct behavior.

Anyway, this has been discussed at length before (e.g. bug 86108, bug 115072,
bug 115753, and many others).  I agree that we need an option for this, but
before an option for this behavior can be considered, we need to handle smart
intermediate behavior for the majority case first (see bug 76672 and bug 152952).

If you are interested, though, both Ubuntu and RHEL4 contain a patch for such a
preference (though both patches are incomplete/buggy, IMO).

*** This bug has been marked as a duplicate of 115753 ***

Can anyone explain to how focus-follows-mouse together with click-raises is
useful, rather than simply saying "nobody wants this, not gonna do it, it's
buggy (how?)"  Why would one want to have full (mouse+keyboard) interactivity
with only the window in front?

As to the "smaller subset/majority" comment, is there anything out there to back
this up?  How much of a majority?  I mean, there's clearly a majority who
prefers to not have focus-follows-mouse at all, but that option's still there. 
How about "Raise selected windows after an interval"?  I'm sure a minority of
users want that as well.

In the meantime I've found the hidden (Ubuntu-specific?) preference
general/raise_on_click, and that'll do the job for me.  But I'd appreciate
further explanation, or pointers to further explanation of the logic behind it
... and not simply people saying "nope".  Bug 86108 has comment after commment
explaining how people /actually use/ don't-raise-on-click, but nothing (that I
see) contradicting it.  Even bug 131135 goes into great detail on the
relationship between raise-on-click and don't-raise-on-click, but never touches
how one would use focus-follows-mouse with raise-on-click. 

You don't see the use for raise-on-click merely because *your* habits are
incompatible with it and that makes having such behavior really painful.  Most
users don't see the use for not raising on click because *their* habits are such
that not raising would be totally useless, plus extremely annoying.  Most all
conversations about this issue just end with each side screaming that the
behavior the other side wants is totally useless and damaging without taking the
time to learn how the other side works (not that learning how the other side
works is very easy--it probably would take at least a couple weeks of forcing
yourself to attempt to work like they do; it took me much longer)

In particular, the majority of people I know who run under Unix/Linux use some
form of focus-follows-mouse.  Out of all of them, I'm the only one who likes
windows to not raise on click (the rest absolutely can't stand it).  See also
bug 115072 about all the complaints when we accidentally changed to not raising
on click.  The basic idea is that users find it non-intuitive to interact with
things which they can't fully see.  It'd be similar to deciding to frequently
place windows mostly offscreen--sure, the users could fix this by dragging the
windows back on screen but it would annoy them to no end.  Also, not raising on
click would be totally useless to them since they tend to place their windows in
such a way that they don't overlap (if they are going to be switching between
two windows often, they'll be absolutely certain to make them not overlap). 
There's only a couple crackheads (like you and me) who see things otherwise,
though we do tend to be highly vocal about the issue because it's not merely
annoying--raise-on-click is fundamentally problematic with the window placement
habits we have developed subconciously.

To address your other points quickly: (1) I didn't claim at all that
do-not-raise-on-click was buggy or that it wouldn't be done.  I intend to do
it--Havoc pointed out that he would consider a patch to allow it but only after
smarter behavior for the majority case was implemented.  I put a fair amount of
time into doing that and will continue. (2) Yes, only a minority of users want
"raise selected windows after an interval" (and I personally think it's a pretty
stupid option), but it is not as difficult for others to understand and further
there's nothing needed to improve in the default case relevant to this option.

Hope that helps...

No, The first time I saw focus-follows mouse it was in Windows (tweakui ;-) ),
where it's raise-on-click.

I couldn't see the use of it then, and can't now.  It wasn't until I tried
Linux, where raise-on-click is optional that I found out why you'd want it.

I think I stated pretty well in the initial bug report the use cases for
don't-raise-on-click.  The only possible one I could see for roc is where there
are multiple non-overlapping windows which one wants to switch between/among
rapidly.  I personally wouldn't take the time to arrange my windows so they
didn't overlap, but I can see the argument for that.  If this is the rationale
behind ffm+roc, I'll accept that.  

I'll admit that my assumption is that most people primarily use the taskbar to
choose a window (based on observation of users at my workplace), and mostly work
in one full-screen app at a time.  The case where I think that makes sense is
web browsers, email, office applications, IRC, games. (I can't imagine working
with a bunch of tiny web browser windows!)

In fact, I really can't think of many cases where the primary usage is going to
be a bunch of non-overlapping windows.  IM and media players are really
secondary functions.  Gimp I suppose.  Maybe file management.  Am I missing a
big one?

I wasn't accusing you of saying it was buggy or wouldn't be done, that was what
I got out of most of the bugs you pointed at in your first response.

Maybe gnome needs a preferences-popularity-contest like Debian's package-popcon. ;-)

If ubuntu is using general/raise_on_click someone needs to kick them out of my
namespace; we might not make that key a bool if we add it.

The rhel setting is /apps/metacity/rhel3_workarounds/raise_on_click

Sebastien: Comment 5 from Havoc is important for you to look at; could you fix
the patch you used accordingly?

k, I'll fix that