Add autoflow caps
Suppose a server hands multiple clients the ability to send to the server. However, almost nothing is unidirectional these days. If the client wants to tightly control the reverse direction flow to it (i.e. the server should only be able to send to the port the client is listening for a response on) --- rather than rewriting the application to choose a non-random port, setup a flow cap to it, and send it to the server's agent --- what if the client could just mark the cap to the server it had already received as an "autoresponse" cap. It is then trivial to install a flow match rule, for any connection-based protocol like TCP, to watch for connection start, create an autoresponse cap owned by the owner of the original flow cap, and install it to allow reverse-path communication.
This allows the client to implicitly grant a cap to itself on whatever port the application might choose, to the server to respond to the client. Because of the connection-oriented nature, the capability can be revoked at connection close or reset (again by installed a flow match rule).
Of course the owner could revoke the autocreated response flow cap whenever it would like.
As far as things like connection drops, well, it is up to the client to ensure those are handled, if it wants to use this mechanism. We could also explore timeouts in the match rules.
I don't know why we didn't think of this sugar, but it's definitely worthwhile and important.