diff --git a/doc/rationale.qbk b/doc/rationale.qbk
index c33788c0..90d982e4 100644
--- a/doc/rationale.qbk
+++ b/doc/rationale.qbk
@@ -44,6 +44,8 @@ bucket but there are a some serious problems with this:
 
 So chained addressing is used.
 
+[/ (Removing for now as this is out of date)
+
 For containers with unique keys I store the buckets in a single-linked list.
 There are other possible data structures (such as a double-linked list)
 that allow for some operations to be faster (such as erasing and iteration)
@@ -63,6 +65,17 @@ nodes in reverse order. This allows quick navigation to the end of a group (sinc
 the first element points to the last) and can be quickly updated when elements
 are inserted or erased. The main disadvantage of this approach is some hairy code
 for erasing elements.
+]
+
+[/ (Starting to write up new structure, might not be ready in time)
+The node used to be stored in a linked list for each bucket but that
+didn't meet the complexity requirements for C++11, so now the nodes
+are stored in one long single linked list. But there needs a way to get
+the bucket from the node, to do that a copy of the key's hash value is
+stored in the node. Another possibility would be to store a pointer to
+the bucket, or the bucket's index, but storing the hash value allows
+some operations to be faster.
+]
 
 [h2 Number of Buckets]
 
@@ -90,24 +103,4 @@ efficiency advantage of power of 2 hash tables.
 
 So, this implementation uses a prime number for the hash table size.
 
-[h2 Active Issues and Proposals]
-
-[h3 C++0x allocators]
-
-/TODO/: This is out of date.
-
-Recent drafts have included an overhaul of the allocators, but this was
-dependent on concepts which are no longer in the standard.
-[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2946.pdf n2946]
-attempts to respecify them without concepts. I'll try to implement this (or
-an appropriate later version) in a future version of boost, possibly changed
-a little to accomodate non-C++0x compilers.
-
-[h3 Are insert and erase stable for unordered_multiset and unordered_multimap?]
-
-It wan't specified if `unordered_multiset` and `unordered_multimap` preserve the order
-of elements with equivalent keys (i.e. if they're stable under `insert` and `erase`).
-Since [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf
-n2691] it's been specified that they do and this implementation follows that.
-
 [endsect]