The NFSv4 specification has provisions in it that allows
for constructing a "Global Namespace" for files.

Let's start by defining what is meant by a Global Namespace.
A Wikipedia search doesn't quite yield what we're looking
for but it results in a link to "Global filesystem" which
oddly enough sortof captures the essence of a global namespace.

So, to rephrase what wikipedia has to say, a Global Namespace 
is a flat namespace where filesystems hosted on a number of 
different servers can be aggregated such that they appear as 
a single filesystem to all the clients. Okay, that sounds
rather dry, just what good is that?

Consider a typical enterprise, for example, Sun. The enterprise
spans multiple countries across multiple geographies. This
brings about a need for separating the IT network that takes
into account the location affinity -- the US west coast users
associate with the .sfbay domain, US central with .central,
UK with .uk, China with .prc and so on. Each location has to
know the names of the servers that host the relevant filesystems
such that those filesystems can be mounted either a priori or
as they're accessed (via the automouter and such). Additionally,
there's obviously the administrative overhead relating to
configuring the mounts or the automounts as well as maps for
the latter.

What if I were to replace this with, say, a single server
(appropriately replicated across .sfbay, .central, .uk, etc)
that acts as the "root" of the namespace? All the clients
across the enterprise need to know just about this single
server (even that might not be needed in the presence of
something like this) from which they mount the root filesystem. 
And, subsequently as they access the directories which don't
exist in, say the .sfbay domain, they get appropriately 
redirected to the server in the .central domain that hosts
these directories (or filesystems to be accurate). The clients
automagically mount the absent filesystem(s) from the .central
server and allow access -- all transparently, without any
user intervention and without the need to configure any
automounter maps.

This is, in essence, a Global Namespace for files (grossly
over simplified but conveys the gist nevertheless).

The NFSv4 protocol allows for such a facility via the
use of Referrals, Replication and Migration. All the 
gory details of this facility can be found in RFC 3530 Section 6
as well as the latest internet draft for NFSv4.1. From
a high level this facility allows for an NFSv4 capable server
to indicate to an equally capable client that a particular
filesystem does not exist on the server in question. The
client can subsequently query the server as to where that
filesystem actually resides to which the server replies with
a list of locations. The client can then initiate a mount
from any of those locations. 

The NFSv4.1 spec allows for the primary server to return a
much richer set of location information as compared those
supported by NFSv4.0. The richer location information allows
for the client to ascertain which of the locations will be
better equipped, for example to deliver a high QoS.

So, ultimately this functionality enables us to tie together
a number of disjoint servers such that they appear as a
single server. Did I mention single? And, given the fact that
we're dealing with NFSv4 and it's a standard protocol helps
immensely -- you can construct a Global Namespace that comprises
of heterogenous servers and clients so long as they support NFSv4
in general and referrals/replication-migration in specific.

The logical next question is - does OpenSolaris support this
NFSv4 feature? No, not yet. But, follow the details here.