I've done some testing with shell scripts that shows a way forward: stop the previous miner, stop X, unload the nVidia driver, reload the driver, restart X, and start the next miner. This puts the GPUs back to a known-good state before getting back to mining. I've switched back and forth between a known-troublesome pair of miners, and it hasn't failed yet. I'm going to put these changes into the switcher next and see how it goes.
This part seems to be working well, but now I'm running into a problem where ccminer (used by several algos) doesn't want to start within a screen session. It works fine if started at the command line by itself. It works fine inside an already-running screen session. It falls on its face when the invocation is preceded by "screen -dmS miner":
/home/m1/SPccminer/ccminer: error while loading shared libraries: libcudart.so.8.0: cannot open shared object file: No such file or directorylibcudart.so.8.0 is in /usr/local/cuda-8.0/lib64.
There appears to be something different in the environment when screen is starting up vs. the rest of the time. Here's a quick hack which fixes it, but I suspect this really shouldn't be necessary:
sudo ln -s /usr/local/cuda-8.0/lib64/libcudart.so.8.0 /usr/lib/
With this fix in place, most miners respond well to the switch...except the Pascal miner. It takes its time responding to SIGTERM, and there's a higher likelihood of a GPU still falling off the bus, locking up, or whatever, necessitating a reboot. Given that it's moving well into negative territory WRT profitability anyway (currently -$0.23 on my rig), I might just disable it and continue testing with the other miners.
I agree that Pascal is essentially useless right now.