Motivation
Armory currently holds address & transaction comments/labels as data appended to the wallet file (zeroed out when replaced/deleted). While it would be nice to keep comments in a separately backup-able file, the data is typically not critical and has not justified the effort to add complexity to the application to accommodate separate backups (or at least a backup that doesn't also include your maybe-encrypted private keys).
P2SH changes this.
Most P2SH scripts will be recoverable if you have backed-up the relevant wallets (which is likely available for personal P2SH/two-factor-auth setups). However, multi-signature transactions executed with other parties, such as escrow or various contracts, is considered critical data. So is the contact information of the other parties in the transaction. Reconstructing your own wallet will not help you find P2SH/multi-sig transactions involving your wallet, and even if you could, it would not help you figure out who the other parties are. You should keep a separate backup of this information.
Partial Solution
The natural solution would be to just maintain this data in a separate file with only P2SH scripts and comments/labels without private keys. This file should be under a regular backup solution. Ideally, a service like Dropbox would backup the data the moment it hits the file, and even protects against corruption by doing automatic versioning of the file. I'm not proposing specific backup mechanism, but simply using Dropbox as an example service that is good for backups, but might raise slight concerns about the privacy of the data stored there.
Full Solution
I propose a mechanism whereby all such data is encrypted using data that is available in your watching-only wallet. The data would be encoded with a header and a body. The header would contain the parent-node-hash160 and the size of the body. It would be followed by the body which will be encrypted via , using some modification of the parent-node-public-key as the encryption key, such as sha256^2(65-byte-public-key).
This encryption is irrelevant for any local backup solution -- since anyone accessing your system will see the watching-only wallet. However, the file can be copied safely to your remote-backup server with absolutely no care for who has access to it.
The benefit of using the parent node is that it's an "address" that is never used. It's is only the root of the particular address chain, but not actually part of the chain, and thus the public key is never exposed. And by using the public key, it allows you to maintain this file even with a watching-only wallet.
The specific choice of which node to use seems irrelevant to me: as long as it's one that isn't used on the network. But it can't always be the wallet's root node, because you may only have access to one or two chains in the wallet. But as long as the message header includes the Hash160 of the parent, it's easy to tell if you have the correct public key in your wallet.
The other maybe-not-so-useful advantage of this is that if you give someone a watching-only chain, you can also give them the entire comments/P2SH file, and they can only decrypt the information that is relevant to that particular chain. Everything else would look like random data to them.
Implementation
The client would be setup, by default, to create this file in the application's home dir. But there would be an option that allows the user to specify a name and directory for it, so that users could have it maintained in a folder that's already backup-protected. All wallet operations that change or add labels or P2SH scripts (or any other supplemental information), would be written to both the regular wallet file (plaintext) and this backup (encrypted).
Of course, there would also be a mechanism for including this file in the wallet recovery process (or post-recovery). Perhaps, if the header information for each entry includes the index/childID numbers, it could additionally assist in wallet recovery search.