Here's a clarification (cc'ed to tech-net since it's worth sharing)..

>   Can you explain what would occur, exactly?

ok, let's assume we have the following scenario:

	{ cloud A }  - if0 - [HOST] - if1 - { cloud B }

Assume we have:
	ifconfig if0 host-if0.foo.com
	ifconfig if1 host-if1.foo.com
	ifconfig lo0 127.0.0.1
	ifconfig lo0 alias host.foo.com

Assume that cloud A has routes to host.foo.com and host-if0.foo.com,
and cloud B has routes to host.foo.com and host-if1.foo.com,

current case:

	-> inbound connections to host.foo.com can come in either
interface; return traffic goes out one or the other (but not both)
based on the routing table.

	-> outbound connections go out one or the other based on the
routing table, and use the address of the outbound interface as the
"source" address of the IP traffic; therefore, they are bound to that
interface.

vixie change:
	-> outbound connections unchanged.

	-> inbound traffic returns over the interface it came in,
	   assuming routing table set up correctly with per-interface
	   default routes.

sommerfeld change:
	-> inbound traffic unchanged

	-> outbound traffic uses host.foo.com as the source address,
	(assuming outbound routes were set up with "-ifa host.foo.com"),
	which means that connections survive cloud B being vaporized.
	(assuming the TCP peer learns the other route to host.foo.com
	via cloud A).	

So, the functionality is completely orthogonal once the routing
table's set up.

The changes to rtrequest() and rtsock.c required to communicate these
sorts of things to the kernel might overlap slightly (I haven't looked
at Vixie's diffs in a long time), but it should be possible to do
both..

						- Bill