When programmers design the programs that install systems, middleware and applications, their first priority is to make the new software function well and look good.
Of less priority is to avoid damaging other functionality, especially the functions of competitive products.
For example.
About 1998 I tried several ISPs; upon installing one of the packages I found that previous IP arrangements that I had spent a few days getting just right had been wiped out.
Apple software at that time supposed, silently, that one computer had at most one IP access arrangement.
Where the results of the substantial effort were squirreled away on the disk(?) was deemed something too arcane for the user to understand.
I have done large documents in word processors with less effort than that required to arrange my IP world.
It is sort of like providing a word processor that hid the work product in an unnamed file.
There was no way to move that work product to another machine or explicitly back it up so that you can experiment with another configuration.
(Apple software is somewhat better now.)

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.