I don't think that Sort is defined the best way in VSIPL.
Why spec doesn't define create function? Such function will let user to
allocate additional memory which are required by some sorting methods.
Why not to define out-of-place sort?
If I work on 64-bit system, sort array of 32-bit FP values and need index
vector, I'll get 64-bit indices which are not supposed to be that long.
This is because last argument of sort function is
const vsip_vview_vi *index and

_vi means (unsigned long int) i.e. 64-bit elements.
In the sort I implemented for AVX I permute data in vector registers and
apply same permute to the indices which occupy other vector register.
It's OK if function has to produce 32-bit indices, but it will be wrong
when I have to shuffle 64-bit values.

This last comment is applicable to other functions as well - index vector
on 64-bit systems doesn't have to be 64-bit value because data arrays
today are not huge yet.

Throughout the document functions are defined with formal sections for "Restrictions" and "Errors".
It isn't clear what the purpose of these two items is. In particular, "Errors" should actually spell out what errors (if any) the given function may generate. What it actually does, however, is specify conditions for the function arguments. These really belong into the "Restrictions" section

While working on the translation to DocBook I noticed lots of small typos ("matrix" instead of "vector", "2d" instead of "1d", references to non-existing functions in "see also" sections, etc.)
While these may all be obvious, i.e. not require any discussion or even semantic changes to the spec, the document needs a careful review to correct these.

VSIPL and VSIPL++ both provide APIs to serialize certain objects. The VSIPL++ API supports serialization of blocks, while the VSIPL API supports serialization of function objects.

The API for both should be unified and made optional (a "profile"), as it is orthogonal to the rest of the spec.