Thanks Christian for looking into this, please find my responses inlined:

> * IMO it should be called after profiling and tracing hook, so non-trivial hooks can be profiled and traced.
Makes sense, Done.

> * It's important to define and document, which thread runs the hook (calling thread or new thread).
Will update documentation when we agree upon appropriate API.

> * Since the hook is designed to monitor thread creation, would it make sense to pass the thread object to the hook?
As it's called within the context of the created thread I guess this is not needed (but as you prefer).

> * How does the hook behave when the callback raises an exception?
I guess it makes sense to do similar thing as in case of profile/trace hooks (Error in the profile function will cause itself unset). WDYT?

> * Is a single hook good enough or should the API behave more like atexit, which supports an arbitrary amount of hooks?
Feels like it makes sense to keep API similar to what profile/trace provides, otherwise it would be inconsistent.


> * Instead of just a creation hook, how about lifetime hooks are also called when a thread ends?
Sounds fine, do you mean two independent hooks (_thread_creation_hook, _thread_termination_hook) or some other form?