rationales.txt currently has reference to bug 86108 (a long extended
flamewar about raise-on-click, which ends in Havoc asking people to
implement do not raise on DND so he can see how that works), bug 115072
(about raise-on-click having been circumvented by a fix to a mozilla bug;
and the subsequent reversal of the mozilla bug patch so that raise-on-click
worked again), and bug 115753 (which contains a patch against an old
version of metacity to allow a user preference for do-not-raise-on-click).
 I think rationales.txt needs a reference to a bug which actually describes
the advantages of both raise-on-click and do-not-raise-on-click and that
includes the subconcious user habits for people from both groups.  Here's a
simple patch that does that:

--- rationales.txt      17 Oct 2003 01:28:11 -0000      1.14
+++ rationales.txt      11 Jan 2004 03:47:04 -0000
@@ -20,6 +20,7 @@
 workspace wrapping: http://bugzilla.gnome.org/show_bug.cgi?id=89315
  
 raise windows on click:
+  http://bugzilla.gnome.org/show_bug.cgi?id=131135
   http://bugzilla.gnome.org/show_bug.cgi?id=86108
   http://bugzilla.gnome.org/show_bug.cgi?id=115072
   http://bugzilla.gnome.org/show_bug.cgi?id=115753

I'll also submit the patch as an attachment in a moment.  But, to make sure
the bug referenced in my patch (i.e. this bug) actually has that
information, I need to cut and paste the summary of the work I've been
doing.  So, here it is (I hope it comes through okay since it's an html
document I'm cutting and pasting from; if there are errors I'll repaste in
an additional comment):

<p>I think I can actually describe both sides with the advantages of
each.  There are two things that I think people may find surprising
from my analysis: (1) I believe that those who prefer to not raise on
click are a small minority (but definitely a loud one), and (2) I
believe that the better choice from a UI point of view is <i>not</i>
the option that I prefer.  In addition, I think there is something
that the current Metacity maintainers might find interesting: A
"compromise" between the two options where windows are raised under
some conditions upon clicking but not others, would (with a small
exception for the raise-on-click crowd) be worse than either extreme
for both groups.</p>

<ul>

  <p>The <i>advantage of raise-on-click</i> (which I abbreviate to
  ROC) is fairly simple.  <!-- Most users do not work with very many
  windows and even when they do, they either have them disjoint on the
  screen (making raising a non-issue) or do not switch back and forth
  very often.  --> Most users find it counter-intuitive (and perhaps
  frustrating) to work with an obscured window and want a simple way
  of uncovering the window they desire to work with if it is not
  already on top.</p>

  <p>The <i>advantages of do-not-raise-on-click</i> (which I
  abbreviate to DNROC) are more subtle.  If you tend to work with lots
  of windows, do not keep them disjoint, and want to switch between
  overlapping windows frequently, then by not having windows raise on
  click you can position those windows so that you can simultaneously
  see the critical portions of all windows <i>and</i> interact with
  them without any of those critical parts becoming obscured as soon
  as you click on one of the windows.  Also, the fact that the windows
  overlap (and usually by significant amounts) also means that the
  user does not have to move the mouse as far between windows to get
  their work done, thus increasing their efficiency.</p>

</ul>

<p>You may not have followed my description for the first advantage of
DNROC.  Let me explain another way.  With DNROC, people will tend to
have lots of windows open.  They will make these windows overlap and
cover up the unimportant parts of various windows.  They can then
interact with all the parts of the windows that are showing.  Giving
them a raise-on-click environment means that clicking on any of those
windows will cause it to raise and suddenly obscure other windows.
This is especially annoying in the case of a small window on top of
and totally surrounded by a bigger window.  Then, any interaction with
the larger lowered window will completely obscure the window on top
due to the automatic raising.  If they want to cut-and-paste from the
lowered window to the smaller window, this suddenly becomes more
difficult as you have to then fish to raise the window again instead
of merely flicking the mouse a little (i.e. moving the mouse over the
smaller window) and then pushing the middle mouse button.</p>

<p>I believe from these descriptions that it is clear that <i>ROC is
far more intuitive and makes much more sense from a UI standpoint for
beginners</i>.  Those that have not used DNROC may not even understand
why it is beneficial, while I'm sure that those in the DNROC crowd who
read my description will understand the reasoning for ROC (though that
won't change their mind one bit about their preference).  Because of
this, let me explain DNROC a little more...</p>

<p>DNROC is about efficiency, not intuitiveness--however, giving DNROC
users a ROC environment results in a major surprise that seems
unintuitive to them and which results in a major slow-down in their
work until they relearn some habits which will allow them to work in a
ROC environment (but, even becoming accustomed to a ROC environment
will never give them the same efficiency that they had in a DNROC
environment).  Because of their surprise, these users will state that
the ROC environment is unintuitive but what will really be bugging
them is that they won't realize why they have habits that are
incompatible with their current environment and they will take a while
to discover (somewhat subconsciously) what the new habits which they
need are.</p>

<p>There are basically two reasons that a user in a DNROC environment
will subconsciously learn over time to aggressively overlap their
windows.  One, there might not be enough room for all the windows
(something that larger resolutions and larger screens will mitigate),
but more importantly, two, because they will learn that when they
overlap windows they do not have to move the mouse as far in order to
do the work they want/need to do.  (People in a ROC environment would
probably also learn to aggressively overlap windows if it were not for
the fact that automatic raise on click means that important parts of
windows must not overlap with even insignificant portions of other
windows or else work becomes much slower).</p>

<p>Some may wonder <i>why an option for the user</i> to choose their
preference hasn't been added before.  Let me address that issue.  To
do so, let me first mention the problems with preferences in general.
Unfortunately, options or preferences are frequently added to programs
when they shouldn't be; these preferences serve to (1) clutter the
interface for the user with extra options, (2) make the code larger
and less manageable, and (3) end up leaving many users to deal with
annoying issues since most users simply use the defaults.  The first
two issues are a problem for all preferences; this means that
maintainers should be very selective about which preferences they
present to their users.  The third issue is something the maintainer
should look at very carefully before introducing any preference, but
is best explained with an example: Some time ago, there was a metacity
bug report asking that the minimized windows be removed from the
Alt-Tab list of switching windows because those minimized windows were
getting in the way.  Other users said they wanted to be able to use
Alt-Tab to get to those minimized windows.  Naturally, people started
suggesting a preference be added so that users could decide which way
they wanted things to work.  The Metacity maintainers were smarter
than that, however, and waited for someone to suggest a real solution,
which is exactly what happened.  Someone eventually suggested that all
minimized windows appear at the end of the Alt-Tab list; this kept
them out of the way for some users while still allowing everyone to
access them.</p>

<p>The metacity maintainers also have been trying to determine whether
an intermediate approach would solve the ROC vs. DNROC problem for
both sides, just as an intermediate approach solved the Alt-Tab
problem.  However, they haven't even been able to get a good
description of the ramifications of the different user interface
choices since people were vocal but no one seemed to understand their
subconscious habits.  (And believe me, it took me forever to figure
out what I have so far about this issue; I would not be surprised if I
still have more to learn about it).  To make matters worse, this issue
is complicated by the fact that there are certain circumstances under
which windows should not be auto-raised even for the ROC crowd.</p>

<p>The main do-not-raise exception I know of for ROC is DND.  Although
windows should normally be raised on left-click, if that left-click is
actually a left-drag (i.e. the user is doing a drag and drop
operation) then the window should not be raised.  This actually has a
similar parallel for DNROC too--in that case, windows can be raised by
super-left-click, but they should not be raised if that
super-left-click is actually a super-left-drag (i.e. the user is
trying to move the window's location).</p>

<p>Basically, however, I believe the advantages of ROC and DNROC as I
listed above are mutually exclusive.  This means that (with perhaps
small exceptions for ROC), a compromise between the two would probably
be worse for both crowds; thus I believe that the maintainers would be
better off either picking one extreme or adding a preference.</p>

<p>So, in summary: (1) I believe ROC is a better UI decision, (2)
those who prefer DNROC are probably a small (but vocal) minority, (3)
I doubt a compromise could be found between the two.</p>