Perhaps I should have been more careful in using the word "every". I am not a full time SW engineer but have done enough coding to see the advantages of modularisation. A custom solution makes sense where it makes sense. Your point about "tweaking" is exactly my point that it is a small change rather than total re-development. I would suggest that code for heat management and battery management would be essentially re-used if there are heat sensor(s) in the body and for the 3 types of battery that Canon uses.
HW will have different capabilities so developing an algorithm for AF detection will work on one processor but not all in their fleet. Clearly the code for the RP will be different to the Digic X platform.
KISS
i am a full time firmware coder and when i read this thread about cut & paste related to porting a firmware on a different model, it's seems that the most people don't know mutch about the hard work of firmware engineering. A firmware for a camera like an R5 is not as simple as coding an Arduino board or a Raspi.
Magic-Latern will be never work on hardware based upon their own developed RTOS called DryOS, that they use since 5DM4, 80D. What's different? The debug interface is not available in the production code and none know's the API's and the handling off. No documentation is public available. All of them was available from VXWorks, the RTOS that canon uses before.
But, i agree in that, that canon is went to an apple iphone price course. Expensive, hi-quality and properitary. But Apple support their devices for a long time - also releases new features if the hardware does'nt limit's.