Some WikiEngines allow the creation of new namespaces: A SubWiki. Every page named X can exist in the main namespace as well as in the various subwikis. When linking to the page X, it depends in which namespace the link exists. It will refer to the page X in the same namespace. To refer to page X in another namespace, it has to be qualified. The exact syntax varies: Foo/X, Foo.X, Foo:X.
Implementations: TwikiClone calls these a Webs, PmWiki calls these Page Groups.
Each wiki also acts as a namespace in its own right. This is unrelated to a SubWiki. A link to page X always links to page X in the same wiki. To link to page X on another wiki, it has to be qualified. Usually a complete URL works fine, but often wiki engines use an InterMap. This map defines "URL Abbreviations" -- each moniker expands to the complete URL of the wiki linked to. The moniker acts as the namespace qualifier. The traditional syntax is Foo:X. See InterWiki for the general idea behind this.
Using a separate wiki per namespace has the drawback that some things are harder to get by, now. Examples:
The missing functionality can be grafted onto a collection of wikis, of course. XmlRpcToWiki is one of the tools that would allow this. UnifiedRecentChanges can list changes to the entire collection, for example.
Some WikiEngines implement imperfect namespaces. The reason being that if you want perfect separation, then you might as well install a separate wiki for every namespace and use an InterMap to link between them. This is only feasible when the WikiEngine is easy to install multiple times, of course. Hairy engines usually have better namespace support, because users need it.
Another reason to favor one big namespace is that the effect of a link X is more difficult to predict if perfect namespaces are in effect. Depending on local context, X will point to different pages. This is not a HumaneInterface.
RecentChanges acts as a bottleneck on attention. Too many changes make PeerReview more difficult. See HijackingRecentChanges. One way to deal with this is to group changes to pages in the same group specially. This does not require separate namespaces. It only has to affect RecentChanges to be effective. This is what PageClusters do.
UseMod allows users to create SubPages to a page. These pages are accessed from outside the group using Foo/X. Within the group, you still need the leading slash: /X. If you just link to X, this will link to the page X in the main namespace. This solution clearly favours one global namespace, since the "default" LinkPattern links to the main namespace only. Since a link X will always point to the same page, the default link pattern is very easy to understand. This is a HumaneInterface. Since the special notation /X will link to different pages depending on context, however, using subpages is not humane.
Using subpages a hierarchical namespace system can be created, much like a directory structure in a filesystem.
FacetWiki implements [[SetBasedNamespace?]]s instead of hierarchical namespaces. In a [tree hierarchy], if page AB is a SubPage of page A, then it can't also be a SubPage of page B. FacetWiki attempts to overcome this restriction. Another important aspect :) of FacetWiki's namespace idea is PeriPeri:ContextualLinking.
Based upon PeriPeri:NearLinks, near links are links that look like ordinary links but point to a different site. If two wikis A and B act as two different namespaces, and they allow NearLinks to each other, then when you link to page X on wiki A, X may point to page X on A, if it exists, or to page X on B, if it does not exist on A but it does exist on B. Clearly, this requires A and B to exchange information on the pages they have defined. SisterSites requires the same kind of information.
See also [CommunityWiki:SetBasedNamespace].