I definitely think that operating systems’ networking APIs and subsystems are far far too basic.
I would like to see firewalling and ACLs available per app with standardised APIs. Also support for QoS type rules behind standardised APIs. It ought to be easy to have named sub pipes so that for example apps could easily put certain types of activity into a named pipe that is shared or exclusive and which has bandwidth limits on it, and also this could be applied to apps without their knowledge or consent, set by a privileged policy definition app. So for example all stars downloads could be put into at least one of three or more sub pipes, one high priority, one or more with a fractional bandwidth limit and one that is background. This would mean that a fast-ish download could be set going but interactive manual web browsing would still not be too painful as the web browsing could be high priority and some bandwidth could always be left free because the fast-ish downloads would be in the limited-to-fractional subpipe.
Very sophisticate schedulers could do things like setting a tiny inter-packet gap for outgoing traffic so that a high priority app such as our manual web browser could always get an outgoing packet in within a guaranteed minimum wait time. But if no such apps are active, then the outgoing stream goes to being absolutely flat out.
We also want a standard o/s-to-o/s control channel so that an o/s can ask the remote end to do throttling and prioritisation and is on, and this would control downloads properly without needing to do ugly and wasteful things like dropping inbound packets prematurely, in the case if TCP, where this is done in order to trick the sender into slowing down, a kludge which is protocol-specific and would not work for UDP in any case. In the case of TCP, delaying ACKs is of course better, but dangerous, since delaying them too long will trigger retransmissions which is a disaster.
We also need o/s group coordination protocols and router/gateway to host o/s protocols that are sophisticated. These should allow such things as groups of machines getting together to coordinate their combined use of a gateway so they leave some free bandwidth on a link; detect idle time in a group so that certain machines can choose to only use a link when it has been idle; get stats on a link’s nature, performance capabilities and current performance stats; detect failover or changes such as when a gateway switches to a backup link, or [shudders] there is a change of routing / addressing that will break transport connections by forcing apps to change source IP address, or there is a change of MTU. The right way to implement a lot of these things is to selectively use IPv6 link-local multicast; multicast for efficiency and link-local and well-known addresses for reliability
Decades have passed and o/s have not got more sophisticated in APIs, policy standards and ACLs and o/s-to-o/s control channels.