When using importlib.metadata.version with tools such as poetry which may install the current package one or more times, importlib.metadata.version is not deterministic in returning the latest version of the package, instead returning the first one located.

As it's unclear if this behavior is desired by importlib, I'm creating this issue to determine if this is intentional behavior or a bug.

I have opened the following poetry issue:
* https://github.com/python-poetry/poetry/issues/5204

I have also created the following reproduction repository for the installation issue:
https://github.com/kkirsche/poetry-remove-untracked

When the after is modified to return the version, it returns the first one found (e.g. if you go 3.0.0 -> 3.0.1 -> 3.0.2, each would be installed and the library would return 3.0.0 to the caller)

Thank you for your time and consideration. I apologize if this is not something that requires action by the Python team.

I'd be open to trying to submit a PR, but want to verify whether this is intentional or not.

The behavior you describe is intentional _and_ deterministic. The library discovers distributions in the order found based on the search path provided, with the search path defaulting to sys.path.

The expectation is therefore that the metadata should be discovered in its order of precedence.

Thanks for the repro. I attempted to follow it, but was unsuccessful:

```
FROM jaraco/multipy-tox
RUN git clone https://github.com/kkirsche/poetry-remove-untracked
RUN pip install poetry
WORKDIR poetry-remove-untracked
RUN git checkout before
RUN poetry install --remove-untracked
RUN git checkout after
RUN poetry install --remove-untracked
CMD python -c "import importlib.metadata as md; print(md.version('poetry-remove-untracked'))"
```

Running that Dockerfile reports that the package isn't installed.

```
draft $ docker run -it @$(docker build -q .)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 955, in version
    return distribution(distribution_name).version
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 928, in distribution
    return Distribution.from_name(distribution_name)
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 518, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: No package metadata was found for poetry-remove-untracked
```

I think you'll have to teach me a bit about how poetry works in order to understand how to properly reproduce the issue so I can examine the relevant environment.

Aha. I learned how to run commands in the poetry environment... and how to locate files in that environment. With that, I figured out where the environment is and where the package metadata is coming from:

```
$ docker run -it @$(docker build -q .) bash -c 'ls $(poetry env info -p)/lib/python3.10/site-packages/poetry*'
/root/.cache/pypoetry/virtualenvs/poetry-remove-untracked-Qran5nGc-py3.10/lib/python3.10/site-packages/poetry_remove_untracked.pth

/root/.cache/pypoetry/virtualenvs/poetry-remove-untracked-Qran5nGc-py3.10/lib/python3.10/site-packages/poetry_remove_untracked-0.1.0.dist-info:
INSTALLER  METADATA  RECORD

/root/.cache/pypoetry/virtualenvs/poetry-remove-untracked-Qran5nGc-py3.10/lib/python3.10/site-packages/poetry_remove_untracked-0.2.0.dist-info:
INSTALLER  METADATA  RECORD
```

In this case, it's clear there is metadata for the `poetry-remove-untracked` package in duplicate, and importlib.metadata loads that metadata in whatever order the operating system provides it (lexicographic alphabetic sort usually). `importlib.metadata` doesn't have any means to determine which of those metadata are appropriate and doesn't support multiple versions of the same distribution being installed into the same path.

Since poetry has acknowledged this issue is a bug, I suspect there's nothing more for importlib.metadata to do here, but do please report back if you have different expectations.

Closing without prejudice. Happy to revisit if there's more information on how importlib could/should behave differently.