I appreciate the detailed insight! Great point on something subtle re individual bulbs that is non-ideal. I'm learning CAN now, mainly for use in drones. I have got 2 STM32 FDCAN periphs talking to each other; the basics seem easy, but the protocols that go on top of it seem complicated! I suppose this is due to managing a decentralized network. Ie, at first CAN seemed like to offer a bus that simplifies wiring and offers resistance to noise, but the more subtle and interesting point seems to be a common API where hardware access is handled by individual nodes, and communication is through this API layer on top of the hardware. Ie, if you control the whole network, it can seem like the first case, but the interesting things happen, eg as you describe, arise when the nodes are by different manufacturers and are swappable.
Ie, with CAN, each node only needs to do reg reads/writes/datasheet-spelunking for a narrow part; the other nodes just need to know the API that sits on top of the hardware.
CAN only really works out well in a complex system if you have full control over the addressing scheme. Addressing and prioritization are one in the same. Unintuitively, prioritization isn't about the importance of a message so much as it is about the message's urgency. A pretty common approach is to use "rate monotonic" prioritization. The basic idea is that higher rate messages have higher priority (lower address) than lower rate messages.
There's rules of thumb about never overloading a CAN bus beyond, say, 50% utilization. That's because systems with poor prioritization management tend to start falling over around there. With a well thought out scheme, it's possible to push a CAN bus fairly close to 100% utilization. I built several safety critical systems that pushed 80% utilization on average. At that level, you really need to rely on redundancy rather than simple robustness, though. A CAN bus running at 80% falls over very hard when you have a flaky physical connection somewhere.
Ie, with CAN, each node only needs to do reg reads/writes/datasheet-spelunking for a narrow part; the other nodes just need to know the API that sits on top of the hardware.