Um. In a way, you have a point. But, to be a devil's advocate, I'll point out that there are such things as subroutines and internal APIs. The general idea is to have any fine-tuning for a particular sensor, or even group of sensors, be placed in a subroutine that can be modified for that sensor; the API to which that sensor delivers data would then look at summary data, and so on.While it's true that Tesla has multiple iterations of (different) hardware they support, I'm positive each requires specific tuning and configuration of the system.
For instance, just in cameras/imaging sensors, you have different characteristics such as:
-Sensitivity
-Resolution
-Bayer-pattern implementation
-Chroma filter wavelengths
-Noise envelope
-Fixed patter noise
-Saturation behavior
-Gamma response
-Aspect ratio
-Field angle
-Temperature sensitivity
-Tolerances
-etc....
And then there's placement around the vehicle (no 2 models are same size/shape), height, angle, windshield rake, etc...
Repeat for each discrete FSD component, and you have a multitude of parameters to account for. It's certainly possible to "generalize" the system such that other components can be used in a different vehicle implementation, but there's a large amount of work to do so, especially for a safety-critical system.
The design, care, and feeding of such APIs is a science unto itself. The APIs themselves aren't necessarily fixed and, potentially, can be made flexible. In fact, that's what Object Oriented Programming is all about, where additional data to be moved about can be added to existing objects, using inheritance so one doesn't necessarily have to reprogram everything.
Having said that, my training was primarily with procedural languages like FORTRAN, BASIC, C, and more assembly languages than I want to count. And the half-dozen operating systems (albeit, for DSP work, but that's pretty slim pickings for an OS developer) that I've had to write. And, being one of those people, there's the downside of OOP code, in that things that can be done ridiculously fast in, say, C, has to spend an inordinate amount of time running around in the structures of OOP code so, well, inheritance works and all. Which doesn't do real-time code any good.
But I keep on running into the occasional article that says that OOP code can be used for real-time fun.
So, to summarize: you have a bit of a point. But I strongly suspect that things aren't as bad as all that, and the people writing the OS and code probably knew that they wanted their work to be extensible and not have to be re-written from scratch every time a bit of hardware got changed.