I'm not sure if you can really call it a "hard" fork. Some people could change the limit today without really effecting the network since we aren't really hitting the limit yet. And it would make the most sense for us to change it now so by the time people start hitting the 1MB limit, it won't be an issue.
Regardless, it isn't really up to the core developers anymore. The developers at slush or deepbit could change the limit today. It'd be risky to try to propagate a block today over the limit, but if the larger miners got together and decided on a date to collectively change the limit, there'd be a higher success rate.
Wrong.
All bitcoin clients will reject a block above 1MB, regardless of what any miner produces.
Thus, it would take a hard fork to change the maximum block size.
This makes very little sense. Why not code the limit into miners only, and have the client simply prefer to relay smaller blocks over larger ones?
Miners & clients are the same thing. Even if you aren't necessarily trying to find the next block, if you are running the client, you are still voting on what blocks are valid & which ones aren't and propagating them appropriately. The problem isn't that blocks over 1MB would be too large for miners/clients to propagate. The problem is that they would see the larger blocks as INVALID.
Lets assume 50% of the miners/clients were running bitcoin instances that accepted blocks over 1MB. It would look like the hashrate dropped in half to both sides. Basically 2 different versions of bitcoin would exist. Mtgox, blockchain, slush, deepbit, etc would all have to decide what side to take. Or they could even fight on both sides. Technically both could exist indefinitely. The prices would probably even be different between the two. Nothing is stopping that from happening...even today. Same problem happens if advances in quantum computing make people want to use a different encryption method.