Currently the validator set hash has the validators sorted by address. If it was sorted by power, it would be simpler for lite clients to verify signatures in order of most power to least power, and stop once they hit 2/3rds of power. While this is already possible when sorting by address, it takes less internal nodes to prove this if they are sorted by power. (Assuming we don't send repeat internal nodes, as that would be silly) I can draw a diagram of this if that would be helpful for the docs.

This would mean that a power update for a validator will require recomputing more internal nodes within the merkle tree, but that seems like a reasonable trade-off. Instead of it taking log n hashes to update, it may now take at most 2(log n) - 1 hashes. (Less if there are more repeated internal nodes, as will be likely, since large power updates seem unlikely)

When gossiping, we communicate the validator set index, thus it is irrelevant if the local storage is done by power or by address. If there is a reason for requiring efficient indexing by address (i.e. for RPC), we can maintain two arrays in the validator set object (one sorted by power, one by address), and only do merkelization / consensus with the one that is by power.