profile include directives are handled at parse time, so the profile library&#39;s representation of a Fedora /etc/krb5.conf file is a single tree.&nbsp; The concerns in this ticket only apply if you do something like KRB5_CONFIG=$HOME/krb5.conf:/etc/krb.conf so that the profile object contains two separate trees.<br />
<br />
Unfortunately, we are not historically consistent about how to handle multiple assignments to a single-valued relation.&nbsp; libkrb5 uses the first value, while libkadm5 uses the last one (presumably following the reasoning you gave about users&#39; intuitions around variable assignment).&nbsp; Changing either behavior to match the other risks breaking existing configurations.&nbsp; In hindsight, I think this is a good argument against using repeated assignments to represent lists in a configuration language, but we can&#39;t do much about that now.<br />
<br />
It is true that beefing up final-flag support would give FreeRDP a way to do what it wants without the profile write APIs, and to handle similar use cases around modifying the default configuration.&nbsp; Perhaps that is a good variant of the null solution: document that modifying the default profile is discouraged, and instead encourage prepending an override tree to the default configuration.&nbsp; I think we might need to provide an additional API to make that easy, as simply including /etc/krb5.conf would not be correct for all process environments.&nbsp; One concern for this direction is that applications would be relying on all-new functionality, whereas the current FreeRDP approach *almost* works with existing krb5.