>> *What* kind of routing?
> The kind of routing where multiple default routes are possible;

I can't see any connection between that and having gateways that are
off-net for all interfaces.

> Where communicating with an ethernet-connected gateway that isn't in
> your specific netmask is simple;

It is?  How do you know which Ethernet?  Then, how do you find it?

> [Much snipped, none of which actually answers my questions as far as
> I can tell.]

I still can't figure out what it would even _mean_ to have a route
pointing to a gateway what's not on-net for any configured interface
address, or where you would expect such packets to be sent.

Hypothetical example:

	Machine has
		le0	10.0.1.1/24 and 172.20.4.9/28
		fxp0	10.0.2.14/24
		ppp0	172.17.9.1 -> 10.0.3.44
		lo0	127.0.0.1/8

Now, we add a default route pointing to 192.168.14.88.  We send a
packet to (say) 10.20.30.40, which doesn't match any of the interface
routes.  Where do you expect it to go?  Why?  How is the OS supposed to
figure that out?

Scrap the second address on le0 if it makes you happier.

> *Many* ethernet segments are shared by multiple networks.

Certainly.  And as far as I can see this fact is totally irrelevant to
the discussion at hand.

Putting this together with what sense I have managed to glean amid what
you said, I get the feeling that you want either

(a) Ethernet treated as a point-to-point interface

or

(b) Some kind of mutant IP, wherein multiple networks may be present on
a given interface and a machine may have an address on fewer than all
of them, but should attempt to communicate directly with addresses on
any of them (presumably, the peer either has a similarly mutant stack
or is not expected to be able to reply - you will also have to address
how a host locates peers on networks like Ethernet where hardware
addresses do not bear any direct relation to IPs).

If you meant something else, it has completely escaped me, and you will
have to explain in more detail.  (Quite possibly, your answer to my
hypothetical example will clarify.)

Neither (a) nor (b) is a totally unreasonable desire.  However, (a) is
not normal IP-over-Ethernet, and (b) is not normal IP.  If you want to
try to implement them, more power to you, but please don't mistake them
for normal IP-over-Ethernet (for (a)) or normal IP (for (b)), and
please don't put ugly kludges into the IP-over-Ethernet (resp. IP) code
that turn conditions that are erroneous for normal use into silent
successes that don't do what someone used to normal functioning expects.

> Regardless of how "correct" such a configuration is, the fact remains
> that in order to communicate with these foreign-local networks the
> NetBSD user must jump through some pretty crazy friggin' hoops.

Yes, if you have a machine using (a), you may have to do a lot of
hoop-jumping to communicate between it and a machine that does normal
IP-over-Ethernet; mutatis mutandis, the same applies to (b).  I fail to
see why it is a deficiency in NetBSD that it doesn't yet do so.  Has
someone already standardized (a) or (b)?  If so, why not just point at
the spec?  If not, how do you expect NetBSD to conform to a standard
that doesn't exist?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B