passphrase mode: currently, you can't change the passphrase in "passphrase" mode as the aes/enc_mac/id_hash key is directly derived from the passphrase. this might come unexpected to the user and is not solvable without starting from scratch. also, one can't change the pbkdf2 iterations count.

keyfile mode: currently, the keyfile is stored locally on the machine which is backed up. so in case somebody does not backup the keyfile separately (not just within the encrypted attic backup), he can't recover as he has lost access to the key if the machine has a fatal mass storage defect.

both problems can be solved like this:

a) kill the passphrase mode as it is implemented currently
b) create a new passphrase mode that works like the keyfile mode, but stores the keyfile data into the backup repository.

From the user's perspective: this means that he is still dealing just with a passphrase. But the passphrase can be changed because the key is not directly derived from it any more.

From an attacker's perspective (who controls your backup storage): this is also equivalent to the old passphrase mode, because knowledge of the passphrase is all the attacker needs to decrypt your backups because the key is stored in the repo in this mode. If one wants to avoid that, one needs to use keyfile mode, which is still available as alternative option as it was before - then attacker would need access to the keyfile on your local machine AND your passphrase.

From the code's perspective: both passphrase mode and keyfile mode are now very similar, just the location of the keyfile (contents) is different (local vs. backup repo).