(The following text is specifically about read-only xlinks. I am not sure if it applies to writable xlinks as wel.)

When I use Plastic, I expect that the contents of an xlinked folder in my workspace is updated at the same time that the xlink itself is updated. Plastic currently requires me to perform a workspace update to download the changes. Me - and everyone else on my team - find this behaviour counterintuitive. I would like to see the following changes in behaviour:

1. When I create or modify an xlink, I would like that Plastic update the xlinked folder contents immediately, rather than require me to create/modify the xlink locally, check it in, and then update the workspace.

2. When I receive an xlink modification as part of merging from another branch to my current branch, I would like that Plastic update the xlinked folder contents immediately, instead of waiting for me to click "Update Workspace".

Reason for change 1: The need to check in the xlink before receiving the new files locally makes it impossible for me to verify the consistency of parent repository + xlinked repo together before checking in.

Reason for change 2: The need to click "Update Workspace" to update the xlinked folder contents means that the "merge from branch X" operation in the UI does not actually guarantee that my workspace includes the changes from the other branch; merge + update is necessary, but only in situations where xlink changes are part of the merge.

Change 2 also means that I can freely choose how I introduce or modify a new code module that most of the team wants to maintain as a separate entity: either by duplicating the code module's files into the current repository, or by xlinking to another repository containing the module. Without change 2, there is a hidden cost to using an xlink: Everyone else on the team that has a work branch in flight will need to click "Update Workspace" after they have merged my in my changes to a work branch, or else it will appear to them that some source files are missing / out-of-date related to my changes. They do not care that I happened to use an xlink, they just expect that after a merge, their workspace is up-to-date (like it is in 99% of cases when merges do not include any xlink changes).