The main question is whether Network MIDI should really be modeled as a

.device

or as a resident service. It is not just a single AppleMIDI device: it needs to discover and manage multiple dynamic peers, maintain sessions and network state, and support both AppleMIDI/RTP-MIDI and Network MIDI 2.0/UMP while exposing the resulting endpoints through CAMD. That makes me wonder whether a Network MIDI service managing these transports and their CAMD endpoints would fit AROS better than separate

applemidi.device

/

networkmidi2.device

drivers.