docs(ADR): support flags with duplicate keys.

[tangenti]

This is proposal for support flags with duplicate keys, as a follow up of the discussion on #1634 and #1644.

The selector semantics change proposed in #1644 will be addressed in a separate ADR.

[netlify]

✅ Deploy Preview for polite-licorice-3db33c canceled.

Name	Link
🔨 Latest commit	fbbeab8
🔍 Latest deploy log	https://app.netlify.com/projects/polite-licorice-3db33c/deploys/686baff68c23c00008348cd8

[toddbaert]

I see this proposal as totally workable, but in conflict with #1634 .

In my mind, the main choice we have here is between the more opinionated, less flexible hierarchical structure of #1634, which comes along with built-in assurances (such as the logical impossibility of having duplicate keys within a set) but makes "flagSetId" a special "key-of-keys" property and invalidates the previous usage of flagSetId, vs this proposal, which is less breaking and more flexible. With this proposal, the existing semantics of flagSetId don't change at all, but we now have to handle a new type of conflict (conflicts within the logical keys created by flagSetId + flagKey).

I think I prefer this proposal slightly because of the non-breaking aspects.

[toddbaert]

After consideration and discussions internally, I think I'm in favor of accepting this over #1634 due to it's flexibility and "less-breaking" nature.

[tangenti]

After consideration and discussions internally, I think I'm in favor of accepting this over #1634 due to it's flexibility and "less-breaking" nature.

Thanks a lot Todd. As Guido pointed out in the comments, I think we could consider different options for the storage layer implementation.

@guidobrei Could you approve the PR if there's no more concerns from you and you believe we're aligned here?

[tangenti]

@toddbaert It seems I don't have the permission to merge the PR. Could you merge the PR if everything looks good to you?