It may be useful to document vector algorithms, so that:

• Users would be able to discover them, and use performance benefits. Like consider using string_view::find_first_of instead of hand-rolled nested loop, where both have comparable effort, but the former is now few times more efficient
• Users are aware of the escape hatch and use it for:
  • Nonstandard requirements. There were bug reports on attempted minmax on NaNs
  • Nonstandard toolset, like [test] Use macro workaround to avoid calling vectorized MSVC algorithms from within a SYCL kernel uxlfoundation/oneDPL#1837
  • Standard dependencies avoidance (/NNODEFAULTLIB)

I'm proposing to document:

• The presence of manually vectorized algorithms
• The fact of activation for some simple built-in types and not activation for complex structs
• The fact of runtime CPU detection and safety for minimum STL required CPU.
• The escape hatches _USE_STD_VECTOR_ALGORITHMS and _USE_STD_VECTOR_FLOATING_ALGORITHMS
• The list of manually vectorized algorithms, including string[_view] and bitset member function

I'm doubt if there's a need to document unexpected behavior, that should still not be a problem for proper use:

• The floating sorting algorithms requirements not to contain NaNs
• The removing algorithms possibly overwriting data in the removed range

I'm proposing not to document something that may become obsolete too quickly:

• The performance expectations
• The exact instruction sets used
• The exact activation conditions
• The mem* functions or __builtin_str* functions optimized algorithms:
  • Likely to become obsolete in some time by having compiler optimization, and follow up STL simplification
  • No escape hatch
  • No extra dependencies when these functions are intrinsics