Fibers as implemented lose their usefulness as scheduler primitives because of their thread local overloading and strict thread binding. If that was fixed they'd be able to be used like coroutines are used for scheduling elsewhere.
From a server/Io perspective this makes sense. The problem is from the apps/users perspective. They ideally need to be able to "just write" without managing buffers, non-blocking, multiplexing etc. That's what the stack solutions give them that no other solution does. I do think a write capable API is OK - that's why I introduced hijack, as imperfect as it is. Of course hijack is hard to implement correctly in the face of 1.0 and 1.1 support, especially if you try to support pipelining. The split boolean design was to allow cow cloneable environment objects only allocating space for bool and some buffer pointers in the case of most requests, with the hijack methods being localled from some preexisting server context.
Unicorn was about deploying rails easily for most people, which it really did. Thin had some other challenges, from the fact that the EM build often had issues with openssl to unintended buffering issues that are fine for short requests but very bad for long requests.
Goliath tried, with stronger marketing, to address the concurrency issues, but Goliath baseline performance was too far behind more basic approaches to make it a viable option. Anyone who benched their apps and/or didn't turned explicitly for it will have seen this very clearly.
I'd love to see it happen. I think about doing something periodically, but for general user use cases its quite a lot of work (as one has to write good primitives first). I don't really deploy much ruby anymore, my last bit is probably going away by 2018. Maybe I'll be back, maybe work will bring me back, but for now, it's someone else race.
Happy Christmas and New years!