But that said, I suspect the big reason is that setting uid and gid with threads is going to be messy no way how you slice it. Making setuid and setgid work per-thread, and then having programs coordinate a privileged loss over all the threads is easier to do since the programmer knows where in their code is an appropriate place to do the privileged loss, rather then having one thread trigger it to happen regardless of what the other threads are currently doing. But of course, there's always the chance a thread doesn't drop it's privileges, and since libc has to emulate the POSIX API anyway it just makes things a lot messier since it has to force all the threads to call the setuid or setgid function without having them call it in code.
But of course, I think it's notable that if you can (And in most cases, you probably can) you should be dropping privileges well before you start threads and the body of your program, and if you do that then this doesn't even become an issue in the first place. I would suspect that this is part of why this hasn't been added to the kernel - the user-space solutions are sufficient simply because most programs don't actually ever call these functions after they've already setup threads.
The problem is even worse than it looks at first glance because setid() can fail per thread and there is no sane way to recover from this in userspace. Atomic syscalls are the only sane API for this and Linux is lacking those.
It has, just not the one the linked article is whining about. "Process level" capability management in modern security architectures is basically never based on uid/gid. The kernel is filled with tools (too many, IMHO) for doing this. Looping over your process to try to change the IDs is the Wrong Thing, basically.
I don't know author's intention. Do you? :-)
My point was a warning about how bad idea is using platform-specific non-standard APIs. As exercise, of course it is fine, that is why I up-voted this history.
I do not know the author's intention; I am not certain. But I'm reasonably confident. And that's a reasonable warning, just a bit of a non-sequitur. Hence my confusion.