1. ok. I should add something about extending the lib + how to rely on ADL.
2. | I'd prefer "primary specialization" to "default" in the comments.
   ok. Is that the correct term?
3. A "specialization" of a template is the result of instantiating
it, so the more accurate term, as given in Vandevoorde and
Josuttis, is "primary template."

5. new intro: 
"When writing generic code that works with Standard Library
containers, one often finds it desirable to extend that code to
work with other types that offer enough functionality to satisfy
the needs of the generic code, but in an altered form.  For
example, raw arrays are often suitable for use with generic code
that works with containers, provided a suitable adapter is used.
Likewise, null terminated strings can be treated as containers of
characters, if suitably adapted.  This library provides the means
to adapt Standard Library containers, null terminated strings,
std::pairs of iterators, and raw arrays, such that the same
generic code can work with them all."

6. > | The Introduction is missing discussion of the use of namespace
> | scope functions to do what heretofore would be done via member
> | functions.  Instead, the example and the sentence immediately
> | following it imply this change of syntax.
> 
> Wouldn't it only duplicate stuff in the two links to CollectionCocept and ExternalConcepts?

In a sense, yes, but what I'm proposing is a much abbreviated
form:

"To allow generic code to work with objects that conform to the
ExternalCollectionConcept, this library provides a set of
namespace scope functions and <A
href="http://www.boost.org/more/generic_programming.html#type_generator">type
generators</A> that provide a standard interface for the required
functionality.  Whereas one might write, "c.end()," to get the end
iterator from a Standard Library container, c, using this
library, it would be written, "boost::end(c)."  This change in
syntax is necessary to make the same interface possible with the
other supported types such as null terminated strings."

7. [boost-book-style]I like colors, so perhaps use the boost-book stylesheets?

9. New range explanation:

I'd say "Iterable" if we have to use an "-able" term.  24.1/7
suggests to me that "Range" might be OK:

  Most of the library's algorithmic templates that operate on data
  structures have interfaces that use ranges.  A range is a pair of
  iterators that designate the beginning and end of the computation. A
  range [i, i) is an empty range; in general, a range [i, j) refers to
  the elements in the data structure starting with the one pointed to
  by i and up to but not including the one pointed to by j. Range [i,
  j) is valid if and only if j is reachable from i. The result of the
  application of functions in the library to invalid ranges is
  undefined.
  
10. Don't make empty part of the Range concept, but have a default
    implementation begin() == end() + spccial treatment of char*,
  
11. documentation: table with entities before other tables

12. Example of how result_iterator is used, necessary:
when designing templated classes

template<class container> struct widget {
    typedef result_iterator_of<container> iterator;
};

13. better external concepts: Thorsten Ottosen wrote:
>>  The documentation that's provided I found
>> sufficient, it's just of a different style than other concept
>> documentation.
>
> ok. I don't think the definition of concepts are that much more
> elaborate. What could be
> much better is the example which could follow normal concept
> standards. Is that what you had in mind?

Yes.

14. Change example code for my_generic_replace.

15. More concepts: random-access range: which have constant
time size(); Cpm matthews latest article.