diff --git a/peps/pep-0725.rst b/peps/pep-0725.rst
index 80c99254b07..13fc866d6f7 100644
--- a/peps/pep-0725.rst
+++ b/peps/pep-0725.rst
@@ -589,6 +589,43 @@ Support in PURL for version expressions and ranges is still pending. The pull
 request at `vers implementation for PURL`_ seems close to being merged, at
 which point this PEP could adopt it.
 
+Versioning of virtual dependencies
+----------------------------------
+
+Once PURL supports version expressions, virtual dependencies can be versioned
+with the same syntax. It must be better specified however what the version
+scheme is, because this is not as clear for virtual dependencies as it is for
+PURLs (e.g., there can be multiple implementations, and abstract interfaces may
+not be unambiguously versioned). E.g.:
+
+- OpenMP: has regular ``MAJOR.MINOR`` versions of its standard, so would look
+  like ``>=4.5``.
+- BLAS/LAPACK: should use the versioning used by `Reference LAPACK`_, which
+  defines what the standard APIs are. Uses ``MAJOR.MINOR.MICRO``, so would look
+  like ``>=3.10.0``.
+- Compilers: these implement language standards. For C, C++ and Fortran these
+  are versioned by year. In order for versions to sort correctly, we choose to
+  use the full year (four digits). So "at least C99" would be ``>=1999``, and
+  selecting C++14 or Fortran 77 would be ``==2014`` or ``==1977`` respectively.
+  Other languages may use different versioning schemes. These should be
+  described somewhere before they are used in ``pyproject.toml``.
+
+A logistical challenge is where to describe the versioning - given that this
+will evolve over time, this PEP itself is not the right location for it.
+Instead, this PEP should point at that (to be created) location.
+
+Who defines canonical names and canonical package structure?
+------------------------------------------------------------
+
+Similarly to the logistics around versioning is the question about what names
+are allowed and where they are described. And then who is in control of that
+description and responsible for maintaining it. Our tentative answer is: there
+should be a central list for virtual dependencies and ``pkg:generic`` PURLs,
+maintained as a PyPA project. See
+https://discuss.python.org/t/pep-725-specifying-external-dependencies-in-pyproject-toml/31888/62.
+TODO: once that list/project is prototyped, include it in the PEP and close
+this open issue.
+
 Syntax for virtual dependencies
 -------------------------------
 
@@ -660,3 +697,4 @@ CC0-1.0-Universal license, whichever is more permissive.
 .. _delocate: https://github.com/matthew-brett/delocate
 .. _delvewheel: https://github.com/adang1345/delvewheel
 .. _rgommers/external-deps-build: https://github.com/rgommers/external-deps-build
+.. _Reference LAPACK: https://github.com/Reference-LAPACK/lapack