I still do not understand your goal... anyway,

>(1) on one tty, i do "ping 127.0.0.2" and on another, i do "tcpdump
>-nilo0".  what i see is:
>
>   # tcpdump -nilo0
>   tcpdump: listening on lo0
>   23:11:02.868037 127.0.0.1 > 127.0.0.2: icmp: echo request
>   23:11:02.868159 127.0.0.1 > 127.0.0.1: icmp: echo reply [ttl 1]
>   23:11:03.892777 127.0.0.1 > 127.0.0.2: icmp: echo request
>   23:11:03.892874 127.0.0.1 > 127.0.0.1: icmp: echo reply [ttl 1]
>   ...
>yet the ping program doesn't recognize these responses.

	echo reply with ttl 1 is generated by ping, to flush route cache
	in ip_output.

>(2) i start with "ifconfig lo1 126.0.0.1" (yes, i have more than one).
>then i ping 126.0.0.2.  here, i get different packet patterns.
>   # tcpdump -nilo1
>   tcpdump: listening on lo1
>   23:12:34.134754 126.0.0.1 > 126.0.0.2: icmp: echo request
>   23:12:35.134750 126.0.0.1 > 126.0.0.2: icmp: echo request
>   ...

	try looking at lo0 as well.   you will see the following packets.
>>   23:11:03.892874 127.0.0.1 > 127.0.0.1: icmp: echo reply [ttl 1]
	again, this packet is generated by ping.

>(3) i see that as soon as i ifconfig lo0, ipv6 automatically assigns it
>   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>   inet6 ::1 prefixlen 128
>and then lo1 gets
>   inet6 fe80::1%lo1 prefixlen 64 scopeid 0x2
>   inet6 ::1 prefixlen 128
>is this a problem?  "route get -inet6 ::1" reports lo0, but i expect
>that's only because it's first in the "list".

	i don't think this is a problem, however, i'm not sure what is the
	specwise correct behavior against lo1.

>(4) not really a problem...more of a question.  what theoretical
>effect would setting IFF_BROADCAST on the loopback interfaces have?

	if we remove special handling for 127.0.0.1, we may want to
	configure 127.0.0.1 with below:
	# ifconfig 127.0.0.1 netmask 0xffffffff
	rather than the default
	# ifconfig 127.0.0.1 netmask 0xff000000	(netmask implicitly specified)

itojun