A little bit confusing behavior on multi-atomic configs request

[AirAgentSDE]

In nemoguardrails/rails/llm/config.py, line 1950 to 1956:

# If key is in both dictionaries and both values are lists, concatenate unique elements
        elif key in dict1 and isinstance(dict1[key], list) and isinstance(value, list):
            # Since we want values from dict2 to take precedence, we concatenate dict2 first
            result[key] = _unique_list_concat(value, dict1[key])
        # Otherwise, simply overwrite the value from dict2
        else:
            result[key] = value

This code leads to an unexpected behavior when reloading default task prompts (such as general or generate_user_intent). If a configuration is designed to override these defaults, it only takes effect if it is placed second in the config_ids field. If the "reloading" config appears first, it gets overwritten by the default settings.

I would expect multiple configs to be atomic and non-overlapping, making the combination placement-agnostic. However, if overlaps do need to be handled, the merging behavior should be intuitive and predictable—following a strict sequence where either the first or the last configuration takes priority.

[AirAgentSDE]

Oh, sorry, I was mislead by my agent, I 've see docs/run-rails/using-fastapi-server/chat-with-guardrailed-model.md said the last should always have priority.