Nice fix — the priority order (ID match → fingerprint match → first entity fallback) is the right call, and it correctly handles the config variants that don't have a model field (flux2_reference_image, qwen_image_reference_image). A few small notes:

1. Unreachable fallback in the fingerprint key

const imageName = config.image?.original.image.image_name ?? config.image?.crop?.image.image_name ?? '';

Per the zCroppableImageWithDims schema in types.ts, original.image is not optional — whenever config.image is set, original.image.image_name is guaranteed to be a string. The crop?.image.image_name branch is therefore unreachable. Not a bug, just dead code. I'd simplify to:

const imageName = config.image?.original.image.image_name ?? '';

2. Edge case: panel open with no prior selection

If wasPanelOpen is true but previousSelectedId is null, the code falls through to state.selectedEntityId = firstEntity.id, i.e. it auto-selects the first entity. Looking at the other reducers (refImageAdded, refImageDeleted, refImageSelected), the invariant "panel open ⇒ a selection exists" appears to hold in practice, so this branch should be unreachable. Worth either a short comment explaining the invariant, or an explicit guard so the intent is obvious to future readers.

3. Fingerprint collision for empty configs

Two reference images of the same type with no model and no image produce identical fingerprints (e.g. "ip_adapter\0\0"). Very unlikely in a recall scenario, and the worst case is just selecting the "wrong" one of two interchangeable empties — so probably acceptable, but worth being aware of.

Thanks for the feedback.

3. Fingerprint collision for empty configs

Two reference images of the same type with no model and no image produce identical fingerprints (e.g. "ip_adapter\0\0"). Very unlikely in a recall scenario, and the worst case is just selecting the "wrong" one of two interchangeable empties — so probably acceptable, but worth being aware of.

Yeah, I was aware of this. As you said, it’s very unlikely and the worst case is selecting the wrong one of the two, so I didn’t think it justified extra complexity and left a comment for now.