Isn't the issue here that setenv breaks getenv rather than setenv "not being thread-safe"?

The issue is that getenv's API is fundamentally unsafe. setenv is fine.

But it should be. And we can make it thread safe very easily. Why the hell should we be limited by POSIX? Why can't we provide features beyond it?

It's access to the environ global that's inherently unsafe. setenv and a modified getenv can be accommodated just fine.

Portability across UNIX platforms.

So portability to you, means that the platform can't add features? I reject portability then.

To me? No, to everyone.

Lets say GNU/Linux does that, what you would do for other UNIX flavours, #ifdef soup?

The goal of standards is exactly to minimize that.

Ifdefs would be required. Or some kind of wrapper in gnulib. Or, like systemd, just non-portability. Your philosophy means stagnation forever. I reject that. Programs that use getenv today will not break. Objection to the existence of a getenv_s is absurd.

The only way we move forward is by trying new things, and we can't possibly get everyone to try a new thing all at once. If the thing ends up being useful, we standardize it.

Back when I cared about POSIX (early 2000's) the difference between what POSIX stated and what UNIX systems offered wasn't always the same.

I guess the situation might have improved.

Actually, it says that it need not be thread-safe. It does not prohibit a good implementation from making it thread-safe anyway.