Apologies, didn't notice this was a new bug. Sending only to it now. There's at least a handful of reasons why you've not see this failure when stopping other systemd-managed applications. None of which, IMO, necessarily point to or imply any weakness or shortcoming in tinyproxy's children stop approach. With the caveat that I've not examined systemd/systemctl's stop code, my opinion now and when first digging into this bug is the same: The likely better solution is small additions or backwards-compatible changes to systemd/systemctl, for technical and social reasons. But I could be wrong.
The seeming stop-state status contradiction you found is not a true paradox, and would likely be resolved relatively soon into looking at systemctl's stop code. It's also likely not an indication that my proof of root casuse code may not be demonstrating what it claims. While this is possible, it's unlikely. The root cause of the issue is almost for sure that systemctl and tinyproxy are "racing" to send kill signals to tinyproxy's child processes, and in cases where systemctl looses the race*, it responds in an undesirable way (in the context of tinyproxy management). *Pretty sure I'm remembering correctly that it's when systemctl looses the race that the false negative stop-states occur, but it might be the opposite.
