This looks relatively easy to fix for the Unix TaskQueue implementation - it has the signal value, calls strsignal on it and passes the string to the callback. Extending the callback signature to include the integer signal value would enable it to receive it and be added to the parseable-output.
The Default TaskQueue implementation uses the return value of llvm::sys::Wait to identify if a signal occurred. The Unix implementation of that function has the signal value, calls strsignal and then returns '-2' with the error message set. The actual signal integer is discarded. The Windows implementation doesn't have a signal value at all - it sets the error message explicitly to a couple of hard coded strings.
Given this, what should the value of the raw number of the signal be in the parseable output on Default TaskQueue backends? Not included at all and just have it added if the Unix TaskQueue implementation is used?
That would be my preference, and then we document that the information may not be available on all platforms (but that if it is ever provided it should not be removed in future versions of the compiler).