RTM_MISS vs RTM_DELETE

[Roy Marples <roy%marples.name@localhost>]

dhcpcd wants to know if a router is unreachable.
Not so it can drop the default route, but so it can start solicitations 
for a new router.

History.
BSD has always announced RTM_ADD for a cloned route with an empty gateway.
I added the symetry for RTM_CHANGE (lladdr was entered or changed) and 
RTM_DELETE (cloned route deleted) in NetBSD-7.

NetBSD-8 removed the notion of cloned routes and also lost the above 
symetry I added. I sure didn't notice until recently.
I've recently added fixes for this and submitted PR's for -9.

But I'm now wondering if this is the correct thing to do.
Now that we no longer have cloned routes, RTM_ADD/CHANGE/DELETE is 
purely an implementation detail.
Infact, rtsock.c r 1.215 added back the announcement of the route, 
requested by ryo@ - I have to ask why as it only says "i intend to 
resolve" but ignores the important outcome.

RTM_MISS is send when the destination cannot be resolved.
IF it has already been resolved but the address is not currently 
resolvable then RTM_MISS is not sent. I don't see how this is done, but 
it seems to be an artifact of ARP as those entries don't expire.

So my question is this - should we remove RTM_ADD/CHANGE/DELETE for the 
no-longer cloned routes and fix RTM_MISS to always be reportable?

Pro: it would reduce route(4) messages and fix the intent
Con: it would break compat with -7 (but already broken in -8 so who cares?)

dhcpcd pro: We don't really care if a node is no longer reachable - we 
only care if, we want to use it and it's not available so from this 
biased perspective it makes sense to fix RTM_MISS.

Sorry for the huge wall of text, but I'd like to get this sorted before -9.

Roy