No, there is requirement imposed by that wording. It's just telling you that you can use allocators with them.

i.e. they have a template parameter that gets substituted with an allocator type.

If those class templates have a precondition that their Allocator parameter meets the Allocator requirements, then those class templates should state that themselves. [allocator.requirements.general] is the wrong place to do that.

So... is the current wording implying that basic_syncbuf<CharT, Traits, NonAllocator> may be well-defined, while basic_osyncstream<CharT, Traits, NonAllocator> results in UB?

No. Like I said, there is no normative requirement being imposed here.

It's just an informative remark saying "hey, there are types in the library that have a template parameter where you can put an allocator". It's not saying "and if you do it wrong you will die".

The list of types is incomplete, which should be fixed, but you should not be trying to infer some deep meaning from this sentence, or from the fact the list is incomplete.

Oh I see. Thank you for interpretation!

The Cpp17Allocator requirement is seldom used in the library spec. Is it intended that most allocator-aware utilities (e.g. containers) don't actually require their allocator_type to be Cpp17Allocator?

Yes. Those places use the magic word "allocator", which is defined in [allocator.requirements.general]p1 (note italics). So, anywhere we say "allocator" we mean a class satisfying [allocator.requirements.general].