The memory allocators of that time were also better than the ones 12 years their prior. That's the point.

The point is that memory allocation shouldn't be a bottleneck either way. If it is the program needs to be optimized or redesigned. Better allocators give you more slack, they don't solve the problem. If the problem is already solved, then a basic allocator isn't going to make a big performance difference because it isn't the bottleneck.

those bad data structures would also cause "damage to speed and interactivity" or whatever. This isn't very hard to understand.

It depends on how much they are used and how much contention there is. Sometimes putting a mutex around things is fine.

But these are extremely common specified functions, they are called everywhere all the time

Not necessarily, especially for C string functions, but they do get linked in so it's a good thing musl makes them small.

I said "backbone", not "bottleneck".

Then the point is lost, because 'backbone' doesn't mean anything if it works. If it isn't a bottleneck in throughput or latency anywhere then the speed doesn't matter.

The other important thing is that better stuff can be included in pieces as it's needed. The reverse isn't true. If you use a big fat C library, you have a dependency that isn't going to get better.

Not really. I have to spell it out apparently: actual programs written by normal human programmers do those things, all the time,

You spelled it out last time, it's just not true in the sense that programs have to have these functions as bottlenecks. Strings, allocators and memory copying can all be dealt with independently, but again it's rare that strings and allocations really need to be the bottleneck and in those circumstances you probably want more than a different standard library anyway.

in the imaginary fantasy land people have in their heads where they make up arguments to themselves about how, if every program was written how they liked it,

I'm not sure what this is supposed to mean, there is nothing I've said that doesn't make perfect sense. If you want something to go faster you can make it go faster. A better allocator pales in comparison to lifting allocations out of hot loops.

My point is the musl is useful and the disadvantages are easy to work around. I'm not really sure what your point is, do you think people are going to force you to use it?

Your point seems to be that if you use a slow standard library and complain, it's not a problem with the slow standard library because you can just reimplement the slow parts independently.

The problem with your argument is that it's a universal argument against performance. And if an argument is universal, then it doesn't have any information value.