Namespace Association
  
   - Came about because trying to solve a problem with STL debug modes
     in a conceptually clean manner, using namespaces to represent
     linkage.

Survey, History of STL debug modes

 - Debug mode to STL well established across implementations

   - bounds checking, iterator consistency, etc. 

   - Cay S. Horstmann, Safe STL
     http://www.horstmann.com/safestl.html

   - STLPort
     http://www.stlport.org/doc/debug_mode.html

   - New Dinkumware?

   - Apple patches to gcc
     http://gcc.gnu.org/ml/libstdc++/2003-08/msg00177.html

   - no doubt there are others...

These modes are all implemented in much the same manner, which can be
generalized as follows:

   include/vector
   namespace MACRO(std) { MACRO(vector) }
   
   include/debug/vector
   namespace MACRO(debug) { MACRO(vector) }

   Where there are two modes for the MACRO:

   cc -DDEBUG -I/include/debug foo.cc
   namespace std_release { vector_release } // release code
   namespace std { vector: public vector_release { } }  // debug code

   cc foo.cc
   namespace std { vector { } }  // release code

Problems and drawbacks with this approach

     - ODR violations if debug and release modes are mixed
       (making this functionality less useful)
      (see odr_1.cc, odr_2.cc, odr_issues_remaining_in_apple_patch)

     - incredibly messy, macros and renaming, shadow headers all over
       the place. 

     - conceptually complex

Alternative approaches
   - using declarations
   - namespace composition (using directives)
   - namespace aliases
   - template aliases

A new approach to implement this functionality: namespace association

   include/vector
   namespace release { vector }
   
   include/debug/vector
   namespace debug { vector: public release::vector }

   #ifdef DEBUG
   namespace std |= debug;
   #else
   namespace std |= release;
   #endif

  - Advantages
      - mixed mode is possible
      - no macros, conceptually clean and clear

See this paper for more information and specifics on grammar and
syntax: n1526

Generalized, other uses for this feature

  - Stated examples are very much geared towards standard library
    implementors, eg a lot of work with namespace std.  It's assumed that
    the prohibition against users adding entities to namespace std
    will not change, and that this feature would only give
    implementors added flexibility.

  - That said, this could support C++ library building in other ways:
    - Backwards compatibility:
      namespace std |= tr1;

    - Evolution of linkage and dynamic libraries:
      namespace exported { ... }
      namespace hidden { ... }
      namespace std |= exported;
      namespace std |= hidden;

      As an language-level abstraction for dynamic symbol link maps
      (where entities defined in exported would be visible symbols,
      able to be linked against by external programs, and entities in
      hidden would not have these properties.)

  - Expectation is that this functionality is generally useful