UAVCAN is about building abstract interfaces to enable more complex systems while keeping things simple and maintainable.
The root of your misunderstanding is that you assume that an ID signifies not only the syntax of the data (how it is composed of primitives) but also its semantics (how it is applied in a particular system). I understand where this misconception is coming from – existing embedded systems generally tend to rely on cruder interfaces where there is often no need to introduce extra abstraction and low-level reasoning is generally effective. This mindset is no longer valid for modern robotic and vehicular systems due to the growing complexity, and it can result in serious scalability problems down the road, increasing the cost and putting a hard ceiling on how complex the behaviors implemented by the system can be.
The syntax of a data type is identified by its name (like uavcan.si.sample.temperature.Scalar.1.0). The semantics are identified by the subject-identifier. The two are orthogonal excepting certain special use cases, of which you can think as singletons in an OOP program, or as well-known UDP/TCP port numbers. In the case of DS-015, for example (the upcoming UAVCAN drone standard), most of the data types (especially those related to sensor messages, etc) are not going to have any fixed subject-identifiers. The detailed explanation and justification for this design choice are provided in The UAVCAN Guide (chapter “Interface design guidelines”).
Vendors are interested in upholding this principle because it expands the set of viable applications of their products. For example, if you manufacture a BMS, you will delegate to the integrator to decide where and how it should be integrated into the system. As a vendor, you would be unable to decide for the user which particular role the battery is going to be serving in the system: is it a traction battery? Which one of several? Is it powering the payload? Every participant of the ecosystem is interested in ensuring that the resulting systems are scalable and evolvable, even if the methods of ensuring these properties may seem non-obvious at first.
The view that the approaches we are proposing are more complex than the traditional alternatives is misguided and arises out of a misunderstanding of how systems are composed of COTS components. Whichever strategy is chosen, the hardware vendor cannot dictate the place and function of the hardware unit within the system (excepting few marginal cases) – at least some degree of configurability is necessary. Keeping this in mind, you can see that our approach does not add complexity or variance to COTS units, but rather it reorganizes the existing variabilities in a different way. Continuing the BMS example, the traditional approach would assume that the BMS has a configuration parameter that sets the instance-identifier for this device (which one of the several batteries onboard would that be?); the architecturally clean approach that we have implemented in UAVCAN v1 prescribes to remove the instance-identifier and configure the subject-ID instead. A convenient analogy is the topic name from ROS, DDS, MQ*, etc.
Concerning the integrator’s user experience, in the case of the drone ecosystem at least, the vendor does not need to get involved at all because eventually the configuration process will be entirely automated away. We have the full plug-and-play support on the roadmap for DS-015 already. The end device does not need to know whether it’s being configured by the human manually or by another device automatically because in both cases the same register configuration API is used. Whether there is a dedicated UI provided by the vendor is entirely irrelevant and it is left out to the vendor’s discretion.
I understand that what we propose is a little unorthodox, but sometimes new things have to be introduced to account for the changes in the environment.