It's intentional. char_traits assumes that all elements of a string can be accessed indirect on plain pointers. So basic_string doesn't support allocators with fancy pointers or references. And we meant to do that.

Let's take the constructor example you called out:

basic_string(const charT* s, const Allocator& a = Allocator());

This constructor allows us to create a basic_string object from a string literal. If we were to change the pointer type, that would no longer be possible.

There is no issue here, as the implementation of the constructor must make a copy of the string pointed-to by the pointer 's' rather than adopt ownership of that buffer. It is that internal copy that must make use of the allocator::pointer type.

Now what about the return value of 'c_str()', should that return an allocator::pointer?

Again, the answer (I believe) is 'no' because this is the function that allows us to pass the string's contents to a legacy/OS 'C' API. It is deliberately returning a raw pointer for a reason.

There was an issue where vector::data was changed to return an allocator::pointer to the internal buffer, and this was changed back exactly because this was intended to support passing to external APIs.

Do we have a use-case where the pointer type of internal data structures of our containers (notably basic_string and vector) need to be exposed through a public API? All my current use-cases for allocator::pointer are specific to the implementation of containers themselves.