Some thoughts about the potential solutions here:<br />
<br />
* The null solution is to document that profile write operations can only affect the first file.&nbsp; This essentially leaves the FreeRDP use case broken for some (probably rare) configurations, as there would be no way to guarantee that the realm KDC values from the default profile are cleared and replaced.<br />
<br />
* We could make profile_clear_relation() work using the final flag, and leave the other modification operations broken for multiple files.&nbsp; This is closer to a comprehensive fix than it first seems, as pretty much any FreeRDP-like use case is likely to start with profile_clear_relation() to clear out any values of affected relations from the default profile.&nbsp; The final flag currently only applies to sections, but we could make it apply to relations as well.&nbsp; The relation and its containing sections may not appear in the first file, so profile_clear_relation() would have to develop additional logic to add a dummy relation and mark it deleted/final if there are values in subsequent files.&nbsp; Although this solution requires a lot of special-case logic within profile_clear_relation(), it requires far fewer changes than any of the following ones.<br />
<br />
* We could augment the tree data model to support the kind of overrides necessary to make all of the write operations work within the first file while semantically affecting the values across all files.&nbsp; For instance, profile_rename_section() might need to place tags in the source and destination nodes of the first file&#39;s tree, indicating that subsequent files&#39; trees should contain no values at the source and the source section&#39;s values at the destination.&nbsp; The number of edge cases for this solution is pretty large, and the profile data model is already stretched pretty fine, but this option provides the cleanest semantics without changing any caller-visible aspects of the profile model.<br />
<br />
* We could create an operation to flatten a multi-file profile into a single tree, rendering all of the write operations effective on data originating from any of the files.&nbsp; This operation could be explicit, or could be implicit on rw_setup() or profile_copy().&nbsp; Making it explicit requires attention from callers, who might not realize it is necessary to handle rare configurations.&nbsp; Making it implicit on rw_setup() calls into question the implicit flush that happens in profile_release(), as the flattened profile would potentially have different contents than the original backing file.&nbsp; Flattened profiles would also need to be marked NO_RELOAD, which might be problematic if flattening is implicit on profile_copy().