Hm, I think you're overlooking the fact that in any case where referrals happen, the host that's being referred to must accept incoming connections. An application waiting for incoming connections is something that's pretty easy to detect for a host stack...
I think you're overlooking that UDP doesn't have the concept of incoming
connections :-)
Seriously, I don't see how we can make any detection/heuristic that can determine whether the identifier needs to be able to survive across e.g. multiple socket calls at the API.
Suppose an application which doesn
1. Client connects to the server.
2. Client asks server do perform X.
3. The server might be able to perform X immediately in which case it returns
the results on the same connection,
or the server says "I'll call you back later".
In the second case we get
4. Client creates listening socket. Tells the port number to the server.
5. Existing socket is closed
6. Later server calls back the client
In this case the server takes the "identity" (getpeername()) from the connection created in 1 as the place to call back. Thus allocating a longer-lived identifier in 4 wouldn't help, unless you want to modify the application.