This is indeed an interesting idea. I'm curious what the devs would think about this idea. It could always be implemented on the test network first.

It's not ten minutes, it is 2016 blocks.

And with your variant: imagine: by some sheer luck, some machine generated a block with a VERY VERY low hash. Then if other machines pick this low hash as a target, most of the blocks that would suit the target otherwise will be dropped. And only after the 2016 block cycle ends, an easier target will be set.

Target is not the thing that only decreases, it may increase (for example, if some nodes leave the network or stop generating, the "still generating" nodes should get a better chance to keep emission at the required level)

Block generation is at roughly every 10-15 minutes right now.  See:

http://nullvoid.org/bitcoin/statistix.php

for a current report on some statistical averages over the last several blocks that have been generated.  Still, the general point is valid.  Some blocks are being generated in under ten seconds from the previous one, but statistical averages still exist.

I do see the variable time between blocks, and in particular the predictive quality about when the difficulty is going to increase as something which could be used as a manipulation target after a fashion, although I should point out that any such manipulation would by definition also require CPU processing ability that approaches at least a substantial minority of the overall CPU strength of the network as a whole which is engaged in creating bitcoins.  

I give that last little exception as I hope it will become apparent that in time there will start to be people dropping out of the bitcoin creation process thinking that the whole effort is futile even if maintaining a connection on the network for the purposes of transaction processing could still be useful.  I'm curious about where that will go over time.

The strength of the network is in the overwhelming number of participants where even somebody with a (temporarily) unused server room at their disposal doing nothing but making bitcoin blocks still is a minority of the overall network.  Furthermore, having a couple of "trusted" participants with server farms who are cooperatively making blocks only enhances this protection for everybody and keeps the would-be miscreants at bay.

The only manipulation that I can imagine where this proposal would help is in the case of an attacker who times the connection and release of significant computing resources on the network, where for some periods of time the CPU server farm is banging out the bitcoin blocks and then leaves the network when the difficulty increases substantially.... waiting for that difficulty to drop back to what it was before it started to make the bitcoin blocks (doing other stuff in the meantime or even simply shutting down).  Such efforts over a prolonged period of time, if successful, could also be derived and even plotted statistically to show an attack was under way.  Randomizing the attacks to make it seem like "noise" would only serve to drop the value of such an attack.  Trying to sneak in under the radar to appear as a "normal" user would end up simply adding strength to the network against other would-be attackers and in the long run be ineffective in their attack.  Attackers would be fighting each other and normal users could simply be oblivious that anything is happening at all in terms of an attack.

Just making a presumption on this particular issue, and I don't have any sort of commentary on what would be a "triggering" event to create these kind of blocks, but here is at least a strategy to keep the network from getting completely bogged down with candidate blocks:

Each potential candidate would obviously have some sort of "fitness" metric to suggest which one is more "fit" than another.  If you are generating a block and the "event" trigger occurs, that node would "broadcast" its candidate to all of its immediate neighbors.... and keep track of which "neighbor" (direct connection to another node) has already had that candidate block transmitted.  It only gets transmitted once to a neighbor (with acknowledgment).

When a node starts to receive candidate blocks, it would perform this "fitness" test and either dump the current block (it has failed a fitness test) or keep the block.... continuing to contact adjacent nodes that have not yet acknowledged receiving the candidate block.  If a new candidate is found that is more fit, it wouldn't re-transmit back to the original source of that block (whatever direct connection sent that block), but it would try to share that with other nodes.  If the node receives the same block from a neighbor, it would consider that node to have also acknowledged the block until all neighbors are essentially working with the same block.

While it would be chaotic at first, the network would calm down very quickly in this situation and settle upon a new block that would be ultimately accepted into the chain.

I do agree that the main triggering event would be the big problem with this kind of scheme, and that would imply some sort of centralized timekeeper to create the events.  I also think that such an event driven block creation system would ultimately give out about the same number of "new" coin blocks as the current system, and it would create much more network bandwidth trying to negotiate "winner".  It would also introduce scaling problems that currently don't exist in the current network.

You wouldn't need to wait until right before the ten minute mark to compare hashes. Ideally, hashes would be compared continuously, for the whole ten minutes, so when the ten minute mark approached, all nodes would already have a pretty good idea of who was going to get the block. I think I2P has a swarm based clock and from what I understand, it's a huge complicated mess trying to accurately achieve and maintain an accurate time, but if somebody did want to go that route, the code is available. I imagine if an attacker had enough nodes, he could manipulate the swarm time to his advantage. Slowing down time when he doesn't have the lowest hash and speeding up time when he does. Of course, if you waited until right before the ten minutes are over, I suppose that probably wouldn't be possible. I don't think a giant rush of hashes being compared, would really bog down the swarm, since each node is only sending out their hash if they haven't received a higher one and only spreading the highest received hash. I think the total time it would not take would be more than the amount of time for the lowest hash to be checked by each node, because it would always win when compared to against other hashes and so it would always be propagated and never held back. Of course then the issue arises that competing nodes have an incentive to lie, but I imagine that's the case under the current system. If user X is only connected to attacking, lying nodes, then if he gets a lower hash than the attacker, then the attacker just refrains from forwarding his hash.

The biggest problem with this approach is you can't audit it after the fact. Consider the case of restarting your client after it's been off for a week. It immediately connects to Mallory's client and asks it for the last week's block chain. Mallory responds with a chain of super-easy blocks, each exactly 10 minutes apart. Now mallory can control your view of the network and transaction history. Oops. And even if you connect to a 'good' node later, you have no way of sorting out which block chain is real, unless you take the higher difficulty - but this raises the problem where an attacker could spend a long time generating a single block, more difficult than some particular historical block, followed by a bunch of easy blocks. It'll take a while to generate, but then Mallory can rewrite history for the entire network.

The biggest issue with this idea except for the bandwidth, is that you won't have a good idea of how many computers are generating in the network, or how hard it will be for generating.

This kind of information is useful when buying/selling bitcoins, as it has an effect on the price.
Also, I wouldn't know myself how easy it will be to generate, possibly wasting CPU power and electricity in my computers.

I rather stick with the system in use today.

The client makes at least 8 connections, kind of random. One would need to control all of those entry points. Not impossible of course, but one rogue client is one thing, but a bunch of good clients, how to do you formulate attacking all of them?

This is simply the Monetarist desire for the rate of monetary increase to equal the output increase of the economy.  It is a false argument the Austrians have debunked for years and is one of the factors which has led us to the situation we currently have.  That's been the FED's policy... to match money growth to economic growth....it's one of their primary mandates, price stability.  NO NO NO.  Price deflation is a GOOD thing.  Your money buys more per unit.  You become more wealthy not only by investing in interest-bearing projects but through the increase in the value of what your savings (which pay no interest) will buy you.  It leads to thrift and investment in projects likely to have a higher return than the rate of price deflation.