 // property, and they can be provided as methods on the collection,
 // for example removeAll(in: Range<Index>) and
 // removeAll(_: (Element)->Bool).
+//
+// If we were to allow reference-counted indices (basically, the
+// current collections model), then an additional design is possible
+// -- let's call it (2)(c) for the purpose of discussion.  This design
+// would be like (2)(b), but won't require extra storage that is used
+// only for safety checks.  Instead, every index would pay a RC
+// penalty and carry a strong reference to the tree node.
+//
+// Note that (2)(c) is still technically possible to implement in the
+// new collection index model, it just goes against a goal of having
+// indices free of reference-counted stored properties.
 
 infix operator ...* { associativity none precedence 135 }
 infix operator ..<* { associativity none precedence 135 }

//
// 2. We can't specify constraints on associated types.  This forces many
//    trivial algorithms to specify useless constraints.
//
// Trees
// =====

//        extra data structure would only increase the constant factor
//        on memory overhead.
//
//                                      | (1)      | (2)(a)  | (2)(b)
// -------------------------------------+----------+---------+-------
//                          memory-safe | Yes      | Yes     | Yes
//    indices are not reference-counted | Yes      | Yes     | Yes
//                         shares nodes | Yes      | No      | No
//             subscripting on an index | O(log n) | O(1)    | O(1)
//                   advancing an index | O(log n) | O(1)    | O(1)
// deleting does not invalidate indices | No       | No      | Yes
// requires extra O(n) storage just ... |          |         |
//                    for safety checks | No       | No      | Yes
//
// Each of the designs discussed above has its uses, but the intuition
// is that (2)(a) is the one most commonly needed in practice.  (2)(a)
// does not have the desired index invalidation properties.  There is
