So the architectural split should be roughly: System/CAMD → defines the device interface applications use

applemidi.device

/

networkmidi2.device

(under contrib) → implement the relevant network MIDI transports and expose their CAMD endpoints/units Application → opens the CAMD device, discovers/selects the available endpoints, and decides how it wants to bind or use them The fact that the driver may internally manage multiple dynamic peers does not change that layering.