Small editorial changes, plus link to a critical paper.

[GlenKPeterson]

I started editing from the beginning.

Next steps:
I didn't try to edit "Invariants for B-trees." I think though that they were developed to store and retrieve data in chunk from much slower media, specifically from spinning disks and used for file systems. See Cormen, Leiserson, Rivest & Stein Chapter 18 p. 484 (third edition) - I know you own it. :-)

History (what little I know):
1972: B-Tree: Rudolf Bayer and Ed McCreight
1998: Purely Functional Data Structures: Chris Okasaki
2007: Clojure's Persistent Vector (and HashMap) implementations: Rich Hickey
2012: RRB-Tree: Phil Bagwell and Tiark Rompf

There's also this which seems relevant, but hasn't been cited much:
http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.14.9450&rep=rep1&type=pdf
I mean to read more of it.

Also, regarding "Invariants for B-trees" I'm having trouble reading it because Rich Hickey (following Chris Okasaki) uses them for immutable Set, Map, AND Vectors. Sorted Set/Map are binary trees which are (I think) a subset of B-trees.

When you say, "can be sorted by a total order" I love the words total order and learned something from even my brief glance at the Wikipedia article. If you're talking about BINARY trees, then you should include sorting by passing a comparator at construction time, and allowing no duplicates. If you're talking about B-trees used for a Vector implementation, it must be sorted externally, and does not take a comparator. Unsorted Maps and Sets specifically do not have an order. So I think you need to break it down into sections for the various uses and specific types of B-trees right from the beginning, or confine yourself to only the broadest blanket statements that apply to all of them.

I have read about B-trees, some of Okasaki's book, and studied Rich Hickey's Vector so that I feel I understand it well. I've glanced at the Ropes. I understand Hickey's Sorted Map/Set well too. There are sections of his HashMap that I do not understand AT ALL. Specifically how it works when there are too many hash collisions. It actually seems to work with objects are implemented with hashCode() { return 7; }. The HashCollisionNode is above my paygrade right now. Anyway, you should know that if I start talking about B-tree HashMaps, I might be wading in over my head.

(l2) "The key associated with each value is also stored with the value"

True for Maps and Sets, false for Vectors.

That's as far as I got today. I'll probably skip this section and try again further on another day. I hope that helps.