David (Abrahams), First of all, I am excited that your proposal has been formally excepted into the TR, since the dichotomy of yours is the way to go. The reason for me to stay at the naming of things is to make you understand that there is a slight possibility of even quite skilled individuals being led astray by the terminology; as to perhaps clarify certain notions in forthcoming revisions. Ok, you saw that there are two orthogonal issued pertaining to the iterator classifications, i.e., traversal and access. In your proposal, dated 1/19, under the section Design, you write: "The iterator requirements are to be separated into two groups. One set of concepts handles the syntax and semantics of value access ... The other set of concepts handles traversal" There you enumerate the various concepts in each "group" (you also use the word "set" later.)
From this I thought it would be safe to use the term "group of concepts" or "concept group" for "set of concepts" or "requirement groups."
So, the traversal concepts is one group and the access concepts another. You have to map these two orthogonal dimensions into the old, simple hierarchy. You choose to make the traversal concept group pivotal, e.g., you "do not provide tags for the purposes of dispatching based on the access concepts." That is fine. Since the old treatment of iterators dealt with only one dimension, they used the word "category." No need to be more specific "back then..." It is a bit confusing if we, in this new two-dimensional iterative world, use "category" *both* for the combined (intersected) concepts, being analogous to the old concepts, *and* for one of the dimensions. In our case, Traversal. We have to make the meta programming facilities, such as the tags used, be backward-compatible, with that I agree. So, we have to keep the "category tag" and "iterator category" and map them to something sensible. We just have to live with the categories, as realized by category tags, dealing *both* with unique combinations of the two orthogonal issues (backward compatibility etc.) *and* with only one of the issues, Traversal, I assume. Could one not make that clear, such as: "category tags can dispatch based on both traversal capability and the combined capabilities of traversal and access" I understand, and always understood, your proposal, which is very welcome, but I do also understand if others might find the mentioning of "category" a bit misleading, since we have the old, combined world, and the new dichotomy to deal with. And... one does, unfortunately, use the word "category" in generic programming for both a single concept and a family of related concepts, often including refinement hierarchies :-| I prefer the less charged word "set of concepts" that you used. Thanks, David