One recent comm package (not from Apple) advised me to write down on paper(!) all of the relevant communications settings so that they could be restored upon disaster. There was no list of which windows might hold state that the proposed installation might step on. This was clearly a case of the technical writer expecting the reader to know more about the system than the writer.
One lesson here, I think, is that substantial work should lead to a named object. At least in the world of communications there is no reason that two such objects cannot exist on the same machine at the same time. Perhaps only one of them at one time can command the real hardware that drives the comm link, modem or whatever.
Another lesson is that an installer should be unable to commandeer a portion of the hardware without permission of the operator. The installers I have described do just that. They leave the machine in a state so that only they can use the communications hardware. Instead rescindable access to hardware should be granted so that the operator can unplug the offending software module and reattach his working mission critical module.
Software technology naturally divides things into modules. There are PPP parameters and IP parameters. I propose that there be distinct kinds of icons depicting distinct types of object. These might be composable by the user, Lego like on the screen, to customize new ways to connect his computer to the world. Such visual modules may exist while they are not in use. This is like the art of plugging sound equipment together. Such imagery can be made to match the concepts that any successful user of computer communications must acquire. Configuring software has a much worse reputation than configuring hardware.
Connecting such modules together with capabilities just as the icons are connected on the screen, assures that cause and effect between modules can follow only the connections that are manifest on the screen. This allows the kind of bug shooting that anyone who has configured hardware is familiar with. An advantage of this world over the hardware world is that software modules may be easily replicated for testing.
A similar but even more complex problem is what MacOS calls system extensions. Some extension functions could be supplied at well defined interfaces whose rules were strictly enforced by capability discipline. I do not claim that the system designers could foresee and design enough such interfaces to enable all the useful system extensions available currently for MacOS. Conflicts between extensions are largely evidence that extension writers go beyond what the system designers had in mind when they wrote the documents that the extension designers code to. Capability discipline will necessarily limit such function but largely avoid extension conflicts.
Here is an outline of an architecture for a standard Keykos installer.