What does the prohibition of "nonstandard" transactions do?

What is included in "GetSigOpCount", and what does "GetSerializeSize" measure?

This is "lightly" enforced by the network:

Won't older clients will reject non-standard transactions, even if newer [future] clients are updated to generate them?

satoshi et al: I have been thinking long and hard about security of the wallet, as I implement other web services that will (I hope) move larger sums of bitcoins. The backup wallet is great, I'm now doing automated backups every time I create a new address, including on sending transactions.

But will this scale on a site that sends many transactions? I always have to backup the whole wallet, and that takes addresses, key, transactions, and grows considerably with usage. For more intensive usage I believe either less backup points or better separation of data is needed.

The two simple solutions I can think of for this are:
1) separate addresses/keys from everything else, so it is easy to do incremental backups or at least limit the backup size to that really needed to recreate the funds in a hardware failure event.
2) implement what has been talked as a future feature, the ahead of time creation of address bundles to be used, so one backup of the wallet is good for 1000 future transactions, or something like that
2.1) to use this efficiently, one should have the possibility to query how many addresses are still left in the unused pool and request creation of a new batch if needed so backups can be timely created and we drop to 0 the possibility of loosing data between address creation and backup

Of course doing both 1) and 2) would be perfect, but can we expect any of the above for a future release? Should we start hacking our own patches?