You are raising a few questions here actually, so the answer won't be simple, and for sure won't be complete. First thing first, this question might be better suited for crypto.stackexchange.com.

A few basic things I'd like to point out:

• Depending on the data size, you most likely don't want to use RSA keys for encrypting that. RSA keys can encrypt only data of up to certain size, which is just under the key length. It's not particularly efficient either.
• I don't think you want to derive RSA keys from user password. This is not what RSA was created for and there is no standard solution to do that. RSA key is just a bunch of large integers, but of certain important characteristics. What I'd suggest to do instead is to encrypt data using a symmetric key derived from user password using one of the *KDF* functions. You can then use static, long-term RSA keys to encrypt the symmetric keys - both master and derived ones.
• As for the password-based key derivation, I believe this is more about key lifecycle management than anything else. One solution would be to store key id for the current and previously derived keys in the metadata of the data it was encrypted with. Assuming the password changes, this will change the current symmetric key id (as well as the key itsefl), but previously derived symmetric keys could be used to decrypt data encrypted in the past. This all assumes keys are effectively rotated on password change, but not never expired.

Apologies for my answer not being as complete as I'd like. However, I think it would be good to take a step back and rethink the original requirements, as what you have described in your question is more like a partial solution. If the community gets to know the original problem, they may be better equipped to provide the best answer possible.

You are raising a few questions here actually, so the answer won't be simple, and for sure won't be complete. First thing first, this question might be better suited for crypto.stackexchange.com.

A few basic things I'd like to point out:

• Depending on the data size, you most likely don't want to use RSA keys for encrypting that. RSA keys can encrypt only data of up to certain size, which is just under the key length. It's not particularly efficient either.
• I don't think you want to derive RSA keys from user password. This is not what RSA was created for and there is no standard solution to do that. RSA key is just a bunch of large integers, but of certain important characteristics. What I'd suggest to do instead is to encrypt data using a symmetric key derived from user password using one of the *KDF* functions. You can then use static, long-term RSA keys to encrypt the symmetric keys - both master and derived ones.
• As for the password-based key derivation, I believe this is more about key lifecycle management than anything else. One solution would be to store key id for the current and previously derived keys in the metadata of the data it was encrypted with. Assuming the password changes, this will change the current symmetric key id (as well as the key itsefl), but previously derived symmetric keys could be used to decrypt data encrypted in the past. This all assumes keys are effectively rotated on password change, but never expired.

Apologies for my answer not being as complete as I'd like. However, I think it would be good to take a step back and rethink the original requirements, as what you have described in your question is more like a partial solution. If the community gets to know the original problem, they may be better equipped to provide the best answer possible.