Right... doing that specialized subset of a language that makes sense for you might not make sense for your team, might not make sense for your next team, and so on.
Plus, every library is using a different subset, so it’s not as if you can stay within your preferred subset either.
I worked in a project that had 6 different string classes: std::string, opencv, vtk, qt … plus a wrapper around all of the above that converted this mess to a plain C string so you could actually use it. A real nightmare, with no good way out.
I’m sure some C++ person will say “it’s not the fault of the language, it’s simply that those libraries are not proper C++23”, missing the fact that those are some of the most prolific, well-maintained and widely used projects in the C++ world. If even those can’t get it right, then the problem must surely lie with the underlying language itself, and with the committee who is defining how it’s supposed to work.
Most likely they do get it right for their problem domain.
If the people who made opencv, vtk and qt had to make it in another language with the design constraints they had (which can sometimes be as simple as insisting on using CamelCase instead of snake_case for historical reasons) they would likely make their own string / array / matrix / ... type in that language too tailored to their exact problem domain.
