That would be useful, but it's probably best to keep scripts stateless. Since different nodes might have different ideas about what the current blockcount is, a situation could develop where half the network considers a transaction valid and half considers it invalid. This is not good for the network.

You may be right about this. Bitcoin's segmentation-fixing mechanisms would seem to keep everything in order.

A similar feature seems to already be planned. Every transaction has the currently-unused "nLockTime" field, and this bit of code exists for the UI (the text would appear in the same place as "x confirmations"):

Sounds very much like what you're thinking of.

We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block.  The OP_BLOCKNUMBER transaction and all its dependants would become invalid.  This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.

nTimeLock does the reverse.  It's an open transaction that can be replaced with new versions until the deadline.  It can't be recorded until it locks.  The highest version when the deadline hits gets recorded.  It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline.  The feature isn't enabled or used yet, but the support is there so it could be implemented later.

OP_BLOCKNUMBER does not introduce any new vulnurabilities compared to the existing system as segmentation can be exploited to defraud people at the moment. This is accomplished as follows:

An opportunistic attacker has clients running in multiple locations around the world. The attacker's clients have the same wallets and connect to different subsets of peers, probably perferring local ones and definitely keeping in touch with local mining peers. The clients communicate with each other at intervals to check whether the network has segmented and exchange the list of peers that they are talking to.
If communication is lost to one or more of the attacker's clients (they go offline) then the remaining clients attempt to communicate with all the offline client's peers. If they all succeed then it's likely that that attacker's client has just crashed or lost its internet connection. If however that client goes offline and a number of the peers are uncontactable then it's possible that the network has segmented. The attacker's clients determine whether they are on the network portion with the majority of the mining power or the minority. They also guess whether the other inaccessible portion of the network has enough mining power to generate blocks over the time it is imagined to be isolated. If the conditions are favourable then the attack proceeds as follows:
The attacker's clients on the majority of the network send coins from the wallet to new addresses in plausible innocent looking transactions. The attacker's clients on the minority of the network use the same coins in the same wallet to buy whatever goods they can find for sale on the subnetwork. When the network joins up again, it's highly likely that the majority part of the network has generated more blocks and all the transactions in blocks on the minority part of the chain re-enter the transaction pool. The attacker's transactions on the shorter chain are discarded as the coins have already been spent on the longer chain. Fraud complete!

So you can see that OP_BLOCKNUMBER does not introduce any new risks and that the real prevention of segmentation-based fraud must rely on some sort of detection of the loss of mining power.

ByteCoin

OP_BLOCKNUMBER transactions are not understood by the current client and their use should come with the proviso that under certain rare conditions problems might occur without any malicious intent. Exactly how rare is made clear below.

At the moment, if you send BTC to an address and for some reason the owner has lost the private key then your coins are lost forever. Payees can lose private keys due to hacking activity, hardware theft, hard disc crashes etc.. OP_BLOCKNUMBER transactions would allow you to recover your money and the transaction could imply a reversion time of months or years in future. In order for a segmentation to accidentally cause problems then the coins would have to go unspent until the deadline was just about to expire at which point the network would have to segment at which point the payee would have to be in the minority portion and try to spend them at which point the network would have to stay segmented until the reversion time had expired. That's a long list of coincidences for it to happen by accident.

On the other hand, exploiting segmentation for double spending is not difficult. Please show me what is difficult about the method I posted. All that is required is one adequately prepared attacker waiting for the network to segment. Anyone on the minority network portion offering goods or services for sale is at risk.

ByteCoin

If there is anything that I've discovered about computers and released software, that any sort of unlikely series of events, not matter how unlikely, are bound to happen in a sort of perverse Murphy's Law sort of situation.  In other words, if it can happen, it will happen and happen in the most annoying way possible.  One sure sign of an amateur software developer, or at least somebody green to the field, is one who dismisses rare or exceptional circumstances to ever happen.

I believe in coincidence and depend upon it to occur even if it is rare.  Indeed a bulk of the computer software I ever write is to deal with those very seldom exceptions with code that is rarely if ever executed.  When you are talking networked computers, the chance for exceptional situation to happen seems to increase even more substantially because there are many more variables involved.  You even get quantum effect showing up where bits get flipped and other hardware "glitches" which cause all kind of other issues.  Sometimes I'm amazed that software works at all half the time.