Hmm. Although the report was already rejected, and even if we all may agree that
the honeybadger code was not brilliant, I feel that the overall issue here in
regards to Threads may be useful for more people in the future too.

For instance, without the blog explanation, where else would you find that much
information about ruby code used for "real"? From the official documentation
of Threads?

http://ruby-doc.org/core-2.3.0/Thread.html

The documentation is not bad at all, mind you, but the blog semi-taught me
more than the documentation would.

There may also be small improvements. We have instance methods like:

"See also the instance methods alive? and stop?"

In the code he checked whether the thread was aborting:

Thread.current.status == "aborting"

This could be simplified if the ruby code would allow
for this check:

Thread.current.aborting?

Or perhaps even

Thread.aborting?

(I do not really know Threads that well that I can suggest an API
that makes sense / is logical.)

Without that block, I would probably have never been able to figure
out that a thread is not just alive or dead but may be in between
the two like the schroedinger cat.

This is not a ruby bug. Thread scheduling is inherently non-deterministic.

Sometimes you'll switch to the work thread before reaching rb_thread_terminate_all which allows the ensure to run, sometimes you won't.

I get that. But why does Ruby wait for the second thread to finish? Or is it that Ruby always waits for those threads to finish, but the Thread gets un-catchable Exception and only runs the ensure blocks and that's what is happening?