It is a middleware. In the API it is viewed as a set of variables accessed with Get, Set, Request, Send. The latter two are to be performed by the hardware. There are further services for creating, waiting, monitoring, enumeration etc. Network is just a “hardware” like CAN, EtherCAT, ModBus etc. When a network variable it is sent the operation is performed remotely and the effect is propagated back asynchronously depending on the QoS settings.
I do not think a middleware should be in the standard.
Distributed annex is more general because it works with all object and all calls. What it lacks: discovery/browsing, dynamic binding, QoS, notification services and an ability to have multiple transports.
Dynamic bindings and asynchronous I/O are interesting challenge. In the middleware each variable has a status. So when a remote host is out the status indicates that. For Ada objects we have no such thing (X’Valid?). Furthermore middleware has a built-in set of types. Distributed annex must work with any type, thus a kind of introspection is required. E.g. if an object is mapped the remote host must check the type/arguments.
It looks like too much work. So maybe leaving it static but allowing transport specification and QoS would be more realistic.