Materializing a default

 1 min settingsd copied a mutable fallback correctly, then lost edits because the copy had never become namespace state.

A missing setting in settingsd could fall back to a default defined elsewhere. To keep one configuration from changing shared defaults, the lookup deep-copied that value before returning it.

The copy was isolated, but it was temporary. If a fragment appended an entry to a default loader list, nothing necessarily stored the changed list in the assembly namespace. The next lookup could obtain another fresh copy of the unchanged default.

The fix added this before returning the looked-up item:

if key.startswith('SETTINGSD_'):
    self[key] = item
return item

The change applied to settingsd’s own SETTINGSD_ configuration keys. Other fallback reads retained the earlier behavior.

The patch also changed the assignment interceptor’s identity check from self[key] to self.get(key). Using the intercepted lookup while deciding whether to record an assignment risked reentering the same materialization path. The check needed to inspect the stored value, not ask for a default through the full lookup policy again.

There are two separate guarantees here. Copying isolates a default from its other users. Storing the copy makes subsequent reads observe the caller’s changes. The first does not imply the second.