In theory you could build this as a library using runtime.Stack and signal.Notify.

I also think this is fairly simple to implement in a separate package, and one might depend on different conditions for it to trigger. Here we are discussing signal handlers, but maybe someone else wants to create a dump when memory reaches a certain threshold, or some other condition is reached. I like the idea of a general api involving runtime.Stack that is triggered by some custom condition and writes to a io.Writer of choice.

I agree that this seems easily implementable outside of the standard library. It also doesn't seem like a common requirement. Is there a good reason to put this in the standard library? See https://go.dev/doc/faq#x_in_std.

It also doesn't seem like a common requirement.

In my experience, enterprise software is exponentially more difficult to support and maintain if simple diagnostics need to be bolted on rather than provided "in the box" (I'm not a Go expert, but I presume "in the box" is equivalent to "inside the standard library"). This feature request was driven by a production incident where we could not get the simple diagnostic of a thread dump that shows what all threads are doing (the program was in a container, so we couldn't easily try pstack either, though I don't know if that even works well with Go). I agree that this feature is easily implementable outside the shared library and that's what we did (though it would be nice if it was provided as a separate package as mentioned above); however, it took weeks to roll it out into production which is the main issue with such bolt-ons. Such built-in handlers are common in other languages such as Java (e.g. using SIGQUIT).