The thing that your computer really filters on is ethernet/MAC address. Every packet destined for your computer is explicitly addressed to your ethernet card (or is a broadcast packet). In a switched environment, this means that, mostly, it never sees any packets that are not for it. But let's say that you're just using simple hubs. The ethernet card will throw away any packets that aren't addressed to the card. (I believe this happens at a firmware level, but I'm not 100% on that.) Any packets that make it through that filter are passed to the IP stack. However, even if a packet was mis-MAC-addressed to your computer and the IP address was in the computer's subnet, the IP stack would throw it away. It's explicitly not listening to the entire subnet. In fact, the receiving end has no concept of subnets.

Where subnets come into play is on the sending end. When you're sending a packet, the first thing the computer needs to figure out is where to send the packet: to a router or "broadcast" on the ethernet segment. When your networking was configured, the system put some entries in a routing table. It put in the fact that your locally configured network is locally attached and that anything other than on that network is to go through a router that you configured. These two routes are the basic ones on any computer. They can be more complex than that, with multiple interfaces or static routes to other networks that don't go through your default router, but the algorithm used is always the same. Compare the destination address of the outgoing packet to the destinations in the routing table, find the one that most closely matches (that is, 10.134.75.0/255.255.255.0 before 10.134.0.0/255.255.0.0, for example) and use its gateway. If it's on a local network, it also needs to figure out the MAC address of the computer it's sending to. This information is kept cached in a table, the ARP table, in the OS. This is handled almost always 100% behind the scenes. When a computer comes up, it usually broadcasts its MAC address on the network with its IP address so that the other computers on the network know the correlation, but if that data has expired from the cache, the sending computer can send out a broadcast request to find an IP address's MAC address. Anyway, it bundles up the IP packet within an ethernet packet and shoots it out onto the segment. When the IP packet is destined for a computer outside its network, it budles up the same IP packet within an ethernet packet with the router's MAC address and shoots it out on the network. The router will receive it and pass it along in a very similar manner based on its routing table. In fact, the end router these days works more along the lines of your "listen to messages from your [subnet]" notion, but only as a result of some added security to prevent spoofing. It used to be that they just listened for absolutely everything and passed it along, regardless of source.

The issue is that there's nothing in the network that has any preconceived notions of network topology until you get to a router. Which just goes to reinforce your initial point even more. Essentially, there are just wires and repeaters. Anything that you send out on the wire will be sent along, even if it doesn't jibe with your netadmin's notions of the network. So if you set up a new IP addresses on systems on the same ethernet segment (which isn't really the right term here), as long as the addresses aren't currently being used globally or locally and both new nodes have netmasks that match well enough, they should be able to talk. There are ways that this might not be the case with some advanced switches, but if the network in question was brought to its knees by a node who took the router's IP address, I'm guessing they're not there.

I hope that's cleared some stuff up, and I hope I haven't made too many mistakes. (Someone jump in if I have.) Also, this is obviously specific to ethernet to some extent, but ethernet and close relatives (that is, mostly CSMA/CD) make up probably 99% of LANs these days, so that shouldn't be a real issue. Besides, I'm not good with token-based LANs anyway.
_________________________
Bitt Faulk