You can do whatever you want, but #1 must be the primary underlying architecture. To do otherwise is foolhardy. (Consider FMEA.) But since that accomplishes the purpose of #2, there's not really much point in implementing more, is there?

CAN would be an excellent choice for distributing ancillary data -- temperatures, voltage and current readings, general health status sorts of things. Tweaking of calibration data, perhaps; but never something that can be set outside of a safe range. For example, a gain factor might be used as 1 + (GAIN_REGISTER / 655360), for a 16 bit signed register value.
None of these are to be depended upon for operation, of course: each module needs its own internal temperature and current and voltage monitoring and all that.
This airs heavily on the side of safety. The root of my concern is that
all software is wrong.* While software
can be made very carefully, and can even be made
provably correct, it is the exception rather than the rule. It's not apparent what level of care might apply here, so I'm assuming the worst.
(*Properly attributed: "Hardware eventually fails. Software eventually works." - Michael Hartung)
So, that goes for microcontrollers embedded in the modules or controller, communications devices, control computers, the whole thing.
I suppose it's curious I leave out hardware design; I personally take great care in my work, so I often overlook this. It's no less critical, of course. Hardware has the advantage that, when designed properly, the possible number of states can be minimized, and probed with relative ease.
In any real software project, exploring the state space is ludicrously impossible. For example, the ~kB of RAM and registers of an ATtiny, giving 2^1000s of total states; which, even if almost all of those states can be disregarded as degenerate states (e.g., the program doesn't -- or, at least, shouldn't -- care if an unused IO register has any random value in it), there's still trillions and trillions of states left to worry about. Software must be written to minimize this count. Put another way, it's the consideration of edge cases, the purity of functions, execution path complexity, all those things and more.
So, all that said: depending on how much confidence you have in that communication link, you might pull some other functions inside the link as well, but pay extra attention to the reliability of the link in that case. There may be some value in a more real-time protocol than CAN (my understanding is CAN silently corrects packet errors, which would be a good warning signal that each module may want to respond to.
Tim