hex dependency resolution shows order dependent behaviour?

Moving issue from https://github.com/elixir-lang/elixir/issues/12519 as this seems to be a hex issue https://github.com/elixir-lang/elixir/issues/12519#issuecomment-1503760546

Elixir and Erlang/OTP versions

Erlang/OTP 25 [erts-13.1.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]

Elixir 1.14.2 (compiled with Erlang/OTP 25)

Operating system

MacOS Ventura 13.2.1

Current behavior

We run into this error while reordering some deps in our mix.exs file.

We were expecting dependency resolution was not relying on the order how the deps were declared in mix.exs

Minimal example, with 2 deps:

  defp deps do
    [
      {:grpc, "~> 0.5.0"},
      {:tesla, "~> 1.6.0"}
    ]
  end

Succeeds:

(base) ~/Workspace/open_source/mix_override_dependency_order(main|✚1…) % mix deps.get
Resolving Hex dependencies...
Resolution completed in 0.032s
Unchanged:
  cowboy 2.9.0
  cowlib 2.11.0
  grpc 0.5.0
  grpc_gun 2.0.1
  mime 2.0.3
  ranch 1.8.0
  tesla 1.6.0
All dependencies are up to date

Switching the dependency order:

  defp deps do
    [
      {:tesla, "~> 1.6.0"},
      {:grpc, "~> 0.5.0"}
    ]
  end

Makes it fail:

(base) ~/Workspace/open_source/mix_override_dependency_order(broken|✚1) % mix deps.get
Resolving Hex dependencies...
Resolution completed in 0.034s
Unchanged:
  cowboy 2.9.0
  cowlib 2.11.0
  grpc 0.5.0
  grpc_gun 2.0.1
  mime 2.0.3
  ranch 1.8.0
  tesla 1.6.0
Dependencies have diverged:
* gun (Hex package)
  different specs were given for the gun app:

  > In deps/grpc/mix.exs:
    {:gun, "~> 2.0.1", [env: :prod, hex: "grpc_gun", repo: "hexpm", optional: false]}

  > In deps/tesla/mix.exs:
    {:gun, "~> 1.3", [env: :prod, hex: "gun", repo: "hexpm", optional: true]}

  Ensure they match or specify one of the above in your deps and set "override: true"
** (Mix) Can't continue due to errors on dependencies

A repo with both versions: https://github.com/danmarcab/mix_override_dependency_order/compare/broken

Expected behavior

We expected hex to behave the same way (not sure if it should work or fail in this case) regardless on the ordering in mix.exs

hexpm / hex