Yeah, given systemctl has to be all powerful (compared to the services, most anyway) it controls, that model makes sense. There are other ways to control processes up and down the 'ring' scopes... if you know OS design, my reference to rings should be familiar. Recall on DG systems, there was a way to access ring 0, to do an emergency stop, basically a controlled crash of the OS, but as I recall this was somewhat unique to DG OS design at the time... long time ago. Definitely a 'Don't ever push the red button' type of thing.
I think my pid isolation logic is the way to go for now for me... Only because I am curious about how it will work as I create it. That is NOT ignoring the systemctl restart methodology that seems ok to do. Knowing systemctl restart is an option, I would say most should use that method for now if they are considering doing an automated NR update flow (initiator).
@JGKK, doing it as a service in the final design definitely is a good idea. Once I get my idea working, will move in that direction. An open question is how I want to 'watch' the progress if at all... for now, NR watching NR does not seem important. Checking for processes that need restart logic I have, Checking for pending reboot logic I have as well, not needed here, but it is part of my current update OS flow. I could just hook NR update into my OS update flow as well, but think I will keep them separate. I don't like cascading changes, makes issue resolution difficult.