Is it possible (in some way or other) to expire a txout? I read Contracts: Will this be possible? where part of the question related to expiring a transaction and one of the replies said that it would never be possible since it causes problems. Unfortunately the reply didn't indicate what problems it would cause.

I can't quite understand from the question/reply whether it was a question of expiring an (unconfirmed?) transaction (which might well be problematic) or expiring a txout from a previously confirmed transaction.

Is the latter entirely impossible by any current method, e.g. scripting and/or a combination of transactions?

One way that I perceive that it might be possible (and I'm only a bitcoin newbie so please take pity on me and help me understand if this suggestion is patently ridiculous to bitcoin experts) would be to have a new bitcoin script operation that could be used in the scriptPubKey of the txout to push the 'current' time on to the stack so that it can be compared (using OP_LESSTHAN, OP_GREATERTHAN, OP_LESSTHANOREQUAL or OP_GREATERTHANOREQUAL) to a fixed expiry time (which is in scriptPubKey and pushed to the stack by scriptPubKey) and only if the current time is less than the expiry time will the rest of the scriptPubKey allow the transaction (i.e. bitcoin payment) to be confirmed.

A note on what I mean by 'current' time...there could be a lengthy debate over the source of current time and the trustworthiness of that source but I'd propose that 'current' time doesn't truly need to be the actual current time so long as it's a reasonably close approximation in the bitcoin realm (about 10 minutes on average but maybe longer, maybe shorter). Thus it could be the timestamp of the previous block in the blockchain; that way every node (assuming no fork) will be judging the txout expiration against the same 'current' time.

An undesirable but arguably acceptable side effect is if a transaction spending the txout is submitted and confirmed in a short blockchain fork then it will get requeued on the longer fork and there is a chance that txout might have expired before the transaction is reprocessed and thus the transaction will fail the second time around.

Another subtlety to aid usability might be to offer two variants of the new 'current' time operation to mirror the two 'variants' of lock_time, one variant to push the previous block's timestamp on to the stack and the other variant to push the previous block's height on to the stack. This way a user can write transactions which are self consistent in time reference or self consistent in height reference.
Expiring a txout doesn't really make sense, since it would destroy the coins, and there is no way to destroy coins. (Coins not spoken for by any txout are contributed as fees.)

You could create a transaction with a lock_time in the future that sends the coins to another bitcoin address. If you give this transaction to a counterparty, they would then have the option to broadcast the transaction to the network after it becomes due, and it would take effect.

Before that time, you could create another transaction without the lock_time restriction, move the coins, and make the counterparty's transaction useless.