Identical encryption keys generated for Ren'Py saves with the same password

Ren'Py allows developers to encrypt save files with a user‑supplied password to deter casual tampering. The encryption routine derives the key via PBKDF2 using a hard‑coded salt value, so every save that uses the same password produces an identical key.

This design means that if a password is reused across projects or shared between users, an attacker who obtains one encrypted save can derive the key and decrypt any other save protected with that password, weakening resistance to rainbow‑table attacks. The current implementation does not expose an option to supply a custom salt or to select an alternative key‑derivation function, leaving the community to weigh security gains against compatibility risks.

What options exist to introduce a per‑save salt without breaking already‑encrypted saves?
Is there a roadmap for exposing a configurable salt or KDF choice in a future Ren'Py release?
How can developers assess the impact of changing the salt on existing save‑file compatibility?