Nope, as you notice yourself, a "posix thread" is a kind of thread, qualified
with the "posix" thingy which indicates that it's not just any thread, but some
specific kind which offers some features generally considered useful.
But the event-handler example shows that in some cases, you don't need those
features and you'd rather have something lighter. The "somthing lighter"
can be a custom-written even-handler, or it can be a "zerofat thread" library
which admittedly, is extremely close to what is sometimes called "coroutine".
The main difference being that coroutines generally denote threads were the
switching is explicit and the the thread switched-to is also explicit, whereas
what is usually called "thread" is just an independent flow of execution,
so you need a scheduler.
Now you can extend your threads in several ways to hang different kinds of
states to its bare "stack+regs", or you can also extend it with "scheduling
guarantees".
My point was that saying "user-threads are useless" is bogus unless you
restrict your threads-world to "posix threads", in which case you overlook many
uses of threads where many aspects of posix threads are just totally useless.
So what we need is a "minimal-thread" library (user-land) associated with a
library of additional features you can add to them. The problem is to make such
a thing both flexible and efficient, as usual.
Stefan