(I'm going to refer to this second item 6 as (7) below.)

Thanks for writing -- you're asking exactly the right questions.  Some
of what I write below follows from the slides I presented at Developer
Day (http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/).

I liked dbaron's followup where he brought up "utility", something from
the Dismal Science that hints at the true nature of our problem
(scarcity, subjective value).  Goals and requirements sound all
scientific, or bureaucratic.  Life isn't that simple, but people often
would rather it were; Armies are great simplifiers, in this sense.

Mozilla is not the Army.  That's the good news.  The bad news is that we
have Redmond's army ants arrayed against us.  We need strong leadership
*and* external allies, if we are to preserve much of the utility
(however subjectively valued) of open standards.

Mozilla can't be a laissez-faire anarchy where staff just resolves
conflicts, because we face not only built-in conflicts, but what's more,
competition from aggressive monopolies and near-monopolies.  Although
Mozilla code will be around for many years, it may become increasingly
irrelevant without two things:

A. Browser user agent market share.

B. *Useful, efficiently implementable, easily authored* open standards
co-evolved with killer applications, such that those standards compete
with counterparts in the proprietary systems (Windows Longhorn,
Macromedia Flex, etc.).

If we do only "the browser thing" (1-3 from your list of goals), we are
likely to be irrelevant in approximately five years.  Not unused, but
trailing-edge; not built upon as a platform, not invested in even as a
hedge.  Yet (1-3) are necessary, even if not sufficient.

Note that (2) and (3) may imply, for certain enterprises and reprobate
sites, supporting the IE DOM, Active X plugins, and other things we'd
rather not support.  If we don't support some of these things, we may
not in fact succeed in competing with IE enough to get sufficient (A).

Why will we likely be irrelevant without more than a good web browser?
The answer is involved; bear with me.

First, Longhorn formats such as XAML will leak onto the web, satisfying
your goals (5-6).  We can predict this with high confidence based on the
IE4 experience.  In 1997, IE4 shipped a better browser, with
non-standard CSS bugs, DOM quirks, and DHTML features, and of course
things like Active X.  By 2000, when IE was crossing the 50% market
share barrier, sites were (intentionally or not) restricting
interoperation to IE clients only.

Another Windows predictor: Windows XP took ~2.5 years to pass 40%
according to Google zeitgeist.

Second, Linux is poised to rise just by being cheaper. "Total Cost of
Ownership" compared to Windows is hard to assess currently, with many
variables, confounders, and hidden costs on both sides.  Some experts
claim Windows has lower TCO right now.  But assume Linux improves and
wins.  This seems a fairly safe prediction, as predictions go --
especially in other parts of the world.

The problem I foresee is that Linux may very well not ship a default
Mozilla browser, relegating Gecko to the category of web-content engine,
soon to be "legacy" web content engine.  In this light, we might make
(4) an anti-goal.  Given trends in at least the GNOME world, the likely
result of the default-browser decision favoring a GNOME browser is that
GNOME/Linux desktops and apps evolve to compete with Windows Longhorn by
solving roughly the same problems in different ways (Mono or no Mono).

The long-term result would be not only a lack of cross-platform apps --
there would be a lack of new cross-platform contents and protocols
needed to countervail XAML and other Longhorn formats, protocols, and
languages.  We can see the beginning of this fragmentation, although not
along OS lines so much as proprietary client lines, with Flex from
Macromedia, Laszlo's XML-based language, and similar children of XUL
from the "rich internet application" platform players.

If Miguel and company clone XAML and Avalon (the harder part to clone),
perhaps in three years Linux will be able to match most of what we can
see coming in Longhorn in the way of open-standards-threatening content.
  But that content will still be relatively or completely closed, under
the control of Microsoft, subject to revision at its discretion.  Not a
pretty picture, even if Mono *eventually* helps apply de-facto or even
de-jure standardization pressure.

What seems worse, though, is the likelihood that XML-based content types
might proliferate and speciate along platform lines: some for Linux,
others for Windows.  Without cross-platform browsers implementing the
same standards everywhere, including the new, non-legacy, ones, the
likelihood of interoperation bugs and outright incompatible/non-portable
formats grows.

In all this, I'm discounting the Mac.  It's an important and influential
niche, one that Mozilla values, but not one likely to grow enough to
make a difference compared to Linux and Windows.  If the OS and
especially the multimedia apps were to be ported to PCs and opened up to
developers on other platforms, maybe -- but those steps would undercut a
lot of Apple's profitability, its platform's strengths, and its appeal
(yes, including its snob appeal).

Here's an alternative that I'm working hard to promote:

I. Build cross-platform apps from the ground up, using Gecko, native
theme-based rendering, and good desktop/OS integration.

II. Promote these apps, starting now -- think Mozilla-the-suite,
Firefox, Thunderbird, Open Office -- on Windows, especially in
enterprises that wish to avoid lock-in, virus hazards, and high license
fees.

III. Let those enterprises migrate to Linux if it makes sense, or defer
the hefty Longhorn upgrade tax by sticking with downrev Windows for as
many years as makes sense.

IV. At the same time, starting now and working closely with other open
source hackers, build a new, unified desktop/web application platform
from pieces of Mozilla and GNOME code, starting now.  Share code and
effort; avoid big rewrites.  Use standards where possible, including the
parts of XUL that are being specified now.  This new platform might even
deserve the "Mozilla 2.0" title.

This new platform must include an advanced rendering layer with hardware
acceleration, fancy effects, animation, video, etc.  We should use what
works now, with as much cross-platform leverage (OpenGL), filling in
gaps on some platforms, and again (always) avoid long-pole scheduling
dependencies where the entire subsystem must be rewritten.

Another characteristic of this new platform: high-level programming
language independence, with a good choice of "managed code" runtimes
(Java, Mono C#, JS2, ...) for type-safe buffer-overrun-free programming.
  We must not keep losing fingers and toes to C and C++; that approach
is a money loser compared to .NET.

A crucial features of this new platform: the GUI toolkit must be able to
blend in among native apps, at least on Windows and Linux, ideally on
Mac too.  There should be a well-specified XML syntax and semantics for
creating user interfaces (XUL) and graphics (SVG or something like it,
but unified), and for composing tags from DOM trees (XBL).  There must
be a low-cost migration path from XUL today to this future language.

I've been busy laying groundwork, building bridges between different
open source projects.  It's still too early to say exactly how things
will turn out.  I don't want to make promises that I can't keep, and a
lot of planets have to align still.  But there is interest among other
key projects' leaders.  I think a number of smart folks see the need for
alliance against the hegemon.

This platform play would address (5-6) by marrying, as much as allying,
GNOME, Mozilla, and perhaps Mono -- bringing cross-platform code and
development to the Linux side, and native next-generation GNOME look and
feel to Mozilla.  It would build something we've been unable to build in
a compelling or complete way by ourselves: a development platform for
arbitrary third party web and desktop apps.

The time frame for this plan is now, with working code by 2nd half of
this year.  Otherwise we're sliding into next year, in danger of being
too late to gain mindshare before Longhorn's inevitability wins the day
for XAML, etc.  So, if this is to succeed, we have major concurrent
development challenges ahead.

I'll answer any questions I can here, and I encourage all comments.  If
something in the analysis above rings false, please say what and why. If
you're following up just one point, feel free to change the subject to
start a sub-thread.

/be