Changing the value of a link's join criteria field causes existing locker entity to become unjoined and a new locker entity to be provisioned

When the value of a field that is used in a Link's join criteria changes, that Join is lost and a new one is created (either via provisioning a new locker entity, or - presumably as I have never attempted it - by joining to a different locker entity if one exists that matches the new field value).

While this might appear to be reasonable behaviour at first, the outcome of this is that when the Join criteria field value of an adapter entity changes it ends up leaving an old entity with the previous value behind, and creating a brand new one with all the same values other than the join criteria field, rather than simply updating the previously-joined locker entity based on the mappings.

Consider:

If I changed the Access Package Name in my adapter from "Admins" to "Sysadmins" I might reasonably expect that change to be mapped through to update my existing locker entity.  Instead, I end up with the old, now-unjoined "Admins" locker entity, as well as a newly provisioned "Sysadmins" entity.  This seems somewhat counter-intuitive: it feels like Joins should have more permanence than that.

Setting Incoming Deprovision to True on the link might appear to be a solution to this, but I may well want to retain locker entities normally (i.e. if the adapter entity was genuinely deleted).  And the deletion/recreation of the locker entity is unnecessary anyway.