Further pondering has brought me to the conclusion that this would be a better idea:
--Future-----
Down the road, it may be thought frugal to replace ID-based lookup with pointer-based lookup. With that in mind, only the red-black tree will need removed, and as such, should be #ifdef'd out of the picture. The rest of the system, including the iterators, remains entirely applicable, though lookup functions in other sources will need minor modification to re-perfect "with" statements...
--Philosophy-----
The system was chosen because precedence was given to CPU time over memory usage. Offering a wide variety of storage methods while using an additional layer of pointers-to-iterators to maintain a uniform iterator saves an entire level of complexity. To prevent extra CPU cycles from a double-dereferencing resulting from the additional layer, the first element in the iterator shall be the element that the "backbone" structure would otherwise have introduced. Because these iterators are unified, many cycles are saved in testing the type of iterator during with, and measures can be taken to avoid more than a single call of overhead, up front.
------------
<For insight, refer to graphic images/link_graphic.svg>
This graphic illustrates the iterator systems at the object-ID level. Note that this does not necessarily imply that every instance listed by iterator is directly an instance of the object given by that ID. The way ENIGMA is structured, heredity as implemented by GM is best emulated by listing all children under each object-ID list. As such, the lists can be redundant, as well as ambiguous, but for the purposes they serve, neither is a problem.
The instance lookup system is a bit more complicated. This takes the same structure we see above, but implements a "backbone," so to speak. Here, a red-black tree (given by std::map) is used to provide lookup with logarithmic complexity. A call to the find function will return, if present, a "with"-ready iterator. In the case of with(int:100000..Infinity), this iterator can be copied and reset such that next points to NULL. In the case of with(int:all), the map can be prodded for begin() and the iterator can be copied as-is and used to traverse the entire list. This is legal as this list is neither redundant nor ambiguous. <For diagram, see images/link_with_backbone.svg>
------------
That's all I really have right now. This will be in a separate box of the same color, right underneath.
That is actually a good foundation for the instance system documentation. Basically, that should look like this:
[future textbox] [philosophy textbox] ; These are indicated with the --NAME----- headings. Nothing divides them between rows.
[banner graphic that spans both cols] ; This is indicated by ^<For (.*), see URL$. Note how this "tag" takes the entire line.
[large text box w/ large span][image] ; This is set off as a new row with -------, then spanned across two columns with an >.
[second large box, with one sentence] ; Same; no image. Image above is float:right because its code carries to the right end.
So basically, a few symbols:
-- indicates a heading start, ----- indicates the end of the heading type.
------- is like above only without a heading given; it creates a normal box.
--Heading----------, with more hyphens, makes the box span two columns.
> Spans the box over a column.
<For ([^,]*), [(see)(refer to)(view)] PATH> includes an image.
- Placing the <> in its own line creates a banner image.
- Placing the <> at the beginning of a line float:left's the image.
- Placing the <> at the end of a line float:right's the image.
- Placing the <> inline, of course, creates an inline image. Like a smiley on this board.
* As the first non-white symbol should signify a bullet, as in an unordered list.