Necessary for making any account-upgrade runtime patch work cleanly (and other things like state-cleaners).

Two ways come to mind (there may be other) that need careful consideration before implementation:

1. Doubly linked list - every extant account references one before and one after. An extra 2 * 32 bytes per account entry. Constant increase of 64 bytes for every account. Account creation and removal need 2 extra key lookups/changes, but traversal needs no extra and no new keys need be stored.
2. Indexed lookup - every extant account is enumerated in a lookup. Needs an extra (index) key to be stored per account, which would be 8 bytes mapping to 32 bytes. On-chain account traversal would need an extra lookup per iteration. Creation would need two extra storage alterations; removal would need one extra removal only. This comes with the added bonus of having a means to reduce transaction size by encoding any AccountIds with just the index.

Option 2 could be optimised by chunking (e.g. indexing 1024 at a time), thereby reducing the amortised lookups to 1 per iteration in on-chain enumeration and the amortised changes to 1 per account creation.

A further optimisation available with either option would be to use e.g. a 16 bit prefix from the account to create multiple independent enumerations, thereby potentially allowing extrinsic parallelism even when extrinsics create new accounts.