0.13.0
should have accompanied the feature.
kill(-n) fell back to the unit THIS program holds whenever n matched no
child. So every negative identifier named the caller's own unit: an enquiry
about a unit that does not exist was answered yes, and a signal aimed at one
ended the caller and everything it led. Measured — a program that formed a
unit and called kill(-99999, SIGKILL) ended on signal 9.
The fallback was written to serve fork(); setpgid(0, 0); exec, and it cannot
serve it: there the unit belongs to the copy and its handle is the copy's, and
openkal handles do not cross that boundary. openkal 0.12 records the whole of it
in clause 11 entry 9. kill(-n) now reaches this program's own unit only when
the caller NAMED it, and answers ESRCH otherwise.
⭐ The coverage gap is the real finding. The whole of setpgid/kill(-n)
shipped in 0.12.0 with its only witness in a consumer's test suite.
examples/subprocess now checks it here, including a control that proves the
observation can fail.
Two README rows described a world two releases old. addchdir_np was
answered in 0.12.0 and the table still said it was not; units arrived in 0.12.0
and the table still said "there are no process groups". Both corrected, and the
permission rows now state what to write INSTEAD of what cannot be written.