are you sure about the nonce not being the hash for the entire string of the entire block?!
I thought that the whole point was that the golden nonce is a proof-of-work, AND a seal of approval on the entire block - say a hash of its CRC.
I thought that this is the mechanism to prevent retro-active changes in the block chain history.
let me rephrase what you are saying, tell me if I got it right: the golden nonce is the hash of simply the previous block nonce, and that the block transactions are just a payload.
so what is the protection against someone changing history, and re-writing one of those transactions, if the nonce doesn't seal them off?
I think you're mixing up the nonce with the block hash. It is the block hash that seals the entire block, or rather the block header. The block header also contains a hash (or rather the Merkle root hash) of all the transactions in the block. So... if any transactions in the block change, the hash in the block header changes, if the block header changes the hash changes.
If that was all there was to it, then the block header would have a fixed hash. The nonce supplies another way of changing the block header. The nonce serves no other purpose so may be completely arbitrarily chosen. Miners try many nonces until the block hash meets the proof-of-work condition.
Given that there is no way of knowing if any particular nonce will be "the one", it doesn't matter if any other fields in the block header change at the same time. In particular the transaction hash. Therefore it costs the miner close to zero to allow an additional transaction into the block, since it's effect is exactly the same as changing the nonce.
As to the extra work for additional transactions, bear in mind that we're talking about megahashes per second machines. The additional work to add a transaction is the recalculation of the Merkle tree, is in the order of say thousands of hashes rather than millions of hashes, then the extra cost is tiny. Further: if we had a GPU doing the nonce search, the little bit of work that the CPU would have to do to add a transaction comes close to being free.
So while there is no reason for miners to add transactions, there's also no reason not to add them either.
If it really became a problem then sociable miners could add a test that said "if there are a thousand pending transactions and new block X contains none of them, then reject the block". It'd be dangerous to do though because it would make block acceptance conditional on out-of-block state.