That’s an interesting practice.
I think an important thing to consider here is that libuavcan platform adapters (I recall we decided to stop using the word “drivers” because of its ambiguity) are user-owned code, just like applications that use libuavcan:
User's application <-- user code
-----------------------------
Libuavcan header-only library <-- our code
-----------------------------
Platform adapter <-- user code*
-----------------------------
Platform (HW/SW)
The entities grouped under “platform adapter” are often to be supplied by users themsevles, despite the reference implementations we provide for popular platforms (STM32, SocketCAN, Kinetis, and LPC11); therefore, it is important to ensure that the interface between the library and the platform adapter is highly stable (at least as stable as the library’s top-side API).
From the user’s standpoint, a platform adapter is not a dependency of the library; quite the opposite: the adapter and the application require the library so they can function together, so the library is a dependee.
Platform adapters may require specific dependencies in the form of VCS submodules (for example, see the AVR platform-specific code for libcanard). Adding such submodules to the common library repository probably isn’t going to work well: a user who needs platform A shouldn’t be affected by one of the submodules required by a platform B becoming unavailable or obsolete.
Another minor argument against a centralized approach was somewhat discussed here: V1 reference hardware. I worry that a single mono-repo with a number of stock platform adapters might lead users to mistakenly believe that the library is designed to function with a predefined set of target platforms only, and that addition of a new platform amounts to a significant work, much like porting an operating system.
In general, in a safety-critical (or nearly so) setting, code changes of any kind shall be minimized. The mono-repo model seems to encourage the opposite by allowing easy changes to the API between our and third-party code (e.g., platform adapter API) and by increased churn due to the need to keep multiple dependencies (of which not more than one is needed by any single user) and auxiliary features up-to-date and working.