extra_toolchains precedence not respected when duplicates occur

[rickeylev]

Description of the bug:

Per #19945, it was decided that elements later in the --extra_toolchains list should have higher precedence. This mostly works, but seems to regress when there are duplicates of a target in the list. When that happens, the first position of a target takes precedence instead of the last.

This isn't too big a deal, but does makes having a --extra_toolchains value with consistent behavior between Bazel 6 and Bazel 7 a bit of a pain. Specifically, there isn't a single list that can get the desired behavior in both versions. For example, lets say we have two toolchain targets, //a:all and //b:all. We want to always use b.

extra_toolchains=[a, b]
Bazel 6: picks a
Bazel 7: picks b

extra_toolchains=[b, a]
Bazel 6: picks b
Bazel 7: picks a

extra_toolchains=[b, a, b]
Bazel 6: picks b
Bazel 7: picks a  <-- err wait what?

# Hm, lets repeat the same value in different ways...
extra_toolchains=[a, b, a]
Bazel 6: picks a
Bazel 7: picks b

extra_toolchains=[a, b, a, b]
Bazel 6: picks a
Bazel 7: picks b

So yeah, it seems like the first position in the list determines the final position when iterating. This smells very much like LinkedHashSet (first added is iteration order), or depset (first iterated upon is yielded, subsequents are ignored) doing something, somewhere.

I skimmed through the RegisterToolchainsFunction.java code, but nothing in particular stuck out to me.

cc @katre

Which category does this issue belong to?

Configurability

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Pass the same toolchain twice using --extra_toolchains. Bazel 7 won't respect the "last has priority" as described in #19945

I can put together a repro tonight.

Which operating system are you running Bazel on?

linux

What is the output of bazel info release?

7.2.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

Not quite a regression, but 75f8017 from #19945 is related

Have you found anything relevant by searching the web?

#19945

Any other information, logs, or outputs that you want to share?

No response