These are very valuable ideas, but I should introduce a few corrections here.
First of all, you seem to have based your reasoning upon the experimental version of the specification, which I boldly call “legacy”, also known as UAVCAN v0. The first stable release which is termed UAVCAN v1.0 differs somewhat from v0; you should familiarize yourself with it here: https://new.uavcan.org/ (if you have strong feelings about the new logo, please head this way: PR preparations for the upcoming UAVCAN v1.0 release: new website, new logo). Important differences between v1 and v0 are that there are no more “data type identifiers”, and that there is native support for data type versioning. A brief but comprehensive recap of the differences is available here, although you may have already read that: Stockholm Summit recap
Second of all, UAVCAN is intentionally designed to be very stateless and robust. Specifically this:
<…> negotiate, establish a connection and subscribe to things <…>
…is not about UAVCAN. The only kinds of dynamic negotiation are the plug-and-play node allocation feature (which is optional and is actually somewhat discouraged by the specification!) and automatic configuration of the physical layer (auto bit rate detection, which is also optional). A typical UAVCAN node is ready to work immediately once powered on, which is emphasized in the spec:
5.2.1 Node initialization
UAVCAN does not require that nodes undergo any specific initialization upon connection to the bus — a node is free to begin functioning immediately once it is powered up.
This is important for UAVCAN because high-reliability applications are among its primary use cases.
Other than above, we seem to be on the same page. It might be an interesting exercise to come up with a working PoC of a declarative node generator as you described, where one defines a high-level node logic using DSDL types and some interface definition schema (not necessarily DSDL-based). Further development of this idea is highly welcome.