The difficulty I see with all of this is that it is hard to communicate to the user what exactly is happening. It is something like this:

1. Requests/procs are always killable, it's just up to you to decide how that kill is handled, if you do things right.
1. If you set call Done with a defer, then
  1. If you set StopCancelPanic, then canceled tasks won't throw a panic into your own code.
  1. Otherwise you can get a panic in your code.
1. Otherwise you can get a panic in your code.

That is pretty complicated. But it could get even more complicated: what if I have my own defer/recover handling for my calls, and there is some cleanup code there? If I set StopCancelPanic, then I might need to duplicate that logic. Also, what if I have created new goroutines from within my task goroutine? Panics/cancels in those goroutines won't be handled by my defer/recover, nor by the defer/recover inside pm, and so my whole program can still crash.

Some of these concerns are universal, and are not related to pm, like handling panics within goroutines created by my task's code. But that is already messy, and I feel like handling panics inside of the pm package is adding complexity to it.

Finally, as a programmer I might want to make some tasks immortal, so they cannot be canceled. This could be important for specific tasks like supervisor goroutines, for example, which I would want to protect against a junior sysadmin who didn't know that some things are sacred and will cause severe problems if killed. (Imagine a complex server process with workers and coordinators, and someone kills the coordinator; the program continues to run, appears to be OK, but does nothing; or worse, does bad things.)

So I feel it would be simpler to make the Status() and CheckCancel() code do something like this:

```go
if !proc.DoNotCancel {
   panic(msg)
}
// else no-op
```

Given that we already have some unavoidable limitations in the way canceling can be handled (we can't cancel if the programmer doesn't let us), it feels like it's trying too hard for something it can't really do anyway.

(Is there a way to use runtime to get a goroutine's ID and kill it...?)