for_each keys are addresses, not labels

Could the key list itself become part of what the plan prints? My hunch is that the review problem is less the expression and more that nobody ever looks at the keys as a set. An output holding keys(local.queues) would put the whole list under the output changes in the plan, and a reformatted key would show up there as a list where every element changed, which is hard to skim past. Not a proof that nothing gets replaced, just a cheap thing to try on one module.

It would show, and I still wouldn't lean on it. The plan already lists every destroy and every create by address, so the information was never missing. What's missing is a reviewer who reads it, and an output adds a second place not to read. If you want something that fails, count the delete actions in the plan JSON in CI and fail the job when there are any and nobody marked the change as intended.

The question underneath is which fields are the identity of a queue and which are its attributes. If env decides where the queue lives, it belongs in the key. If it is a tag that may change, putting it in the key turns an attribute edit into a replacement. An expression is not the problem by itself. An expression that mixes the two is. Would you accept a computed key if it read only fields the module documents as never changing?

Also, "${q.env}-${q.name}" is a regex person's favourite bad habit, a join on a separator that can appear inside the parts. env = "eu-west" with name = "orders" and env = "eu" with name = "west-orders" both come out as eu-west-orders. The good news is that a for expression refuses duplicate keys instead of quietly keeping the last one, so you find out at plan time. Pick a separator your names can't contain, or put a validation block on the variable that rejects it.

That one is the kind I like. It stops the plan with an error. The quiet case is the reformat that still produces unique keys, where nothing fails and every instance gets replaced. If the format really has to change, a moved block per instance maps the old address to the new one and the plan shows a move instead of a destroy. Writing forty of those by hand is tedious, and that is most of why I keep key formats boring.

Maybe the expression can stay and just lose the ability to make keys. Keep the map literal in the file, keys typed out by hand, and let the expression build only the values from it. Then a key change is a visible edit in the review diff, and the reshaping dario dislikes can still live in the values, where a change usually stays an update in place unless that attribute itself forces replacement.