Ok, I understand you're calling this out-of-bounds. I would suggest calling this out clearly in the documentation.
Yes, I will update the documentation to clarify this, thanks for the suggestion.
I do not think that my suggestion of placing the children of s6-svscan in a separate process group from s6-svscan itself changes any of these objectives.
It doesn't indeed, but it's unnecessary. The supervision tree can be seen as one entity, despite it being multiple processes; having the s6-supervise processes in separate sessions or process groups does not bring any benefits - quite the contrary, if you lose the s6-svscan process and want to rebuild the supervision tree, you have to kill every s6-supervise process by hand, which is tedious. Really, since having a controlling terminal for the supervision tree is a very uncommon case that should stay uncommon, I want it to have the least possible amount of code dedicated to it, and to keep the default Unix behaviour wherever possible.
The other thing I thought of is the asymmetry that although s6-svscan handles SIGINT, I notice that s6-supervise does not handle this signal. Perhaps this is a different point that could be considered. If s6-supervise receives SIGINT, it could send SIGINT to the process group it is supervising.
See above - I don't particularly like s6-svscan handling SIGINT, and wish I could leave it out entirely. Unfortunately, it's a requirement for it to be able to run as process 1, since Ctrl-Alt-Del sends a SIGINT to process 1. -- Laurent