The design seems sound. I really, really want to keep the operator syntax, using
the pipe symbol, but this should not be the only or primary way to access the
functionality, since syntax is not general enough for the general case.

The 'ed naming is not good, and for consistency across Boost the _view
naming should be used.

However, in my mind map each of the adaptors is a verb rather than a noun, so
the expression should read as

rng | sort | unique

rather than

rng | sort_view | unique_view

Whereas when the function invocation syntax is used the _view naming seems to
express the intent more clearly. ie

unique_view( sort_view( rng ) )

I haven't looked at the implementation in detail, but it seems well behaved,
appropriate detail hidden etc.
 

Adequate but sparse. The nature of  the lazy evaluation could be made more
prominent, and the mapping of adaptors to existing Boost or STL algorithms
specified, and maybe tabulated.
 

Hugely useful, and becoming increasingly necessary. Ranges rather than
iterators are becoming the focus of thought, and this library is beginning to
look like a glaring omission from Boost.

I've been using various snapshots from the vault for months, under GCC 3.4.4 and
MSVC 8. I haven't noticed any probs, but my use does not constitute comprehensive
coverage.

More than a quick glance, close to in depth study, but patchy.
 

No more than average.
 

YES YES YES YES YES!