Suppose I add a Profile Settings component for Profile A to version 1.0 of a managed package.
I install my package in an org, and create a new Profile, B, cloned from Profile A.
In my packaging org, I add a new field, configure field-level security for Profile A, and create version 1.1 of my package.
When I install version 1.1 in the customer org, do the new settings for Profile A apply to profile B?
This is the way I believe it works:
That relationship between profiles does not persist outside of profile creation. It is done simply to give a base of the permissions to start with. After a profile is created, any changes to the original profile do not change the other profiles as there is no connection between them.
It absolutely does not carry over and is just to make it easier to create a new profile as stated.
Definitely not, which is a good thing. However, if your goal is to have a single set of permissions that you want to be able to evolve over time, you can package and deploy permission sets, which may be a better option for you.
The question reflects a misunderstanding in how Profile Settings work. The Profile isn't included in the managed package so it's not possible to clone profile A, created in the packaging org, as profile B in the customer org.
The packaged Profile Settings are used during package installation to grant access to profiles that exist within the org in which the package is being installed. When prompted to choose the security level, selecting "Select security settings" allows the settings from the packaged Profile Settings, e.g. those from profile A, to be assigned to profiles in the org, e.g. profile B.
