PEP 665: more clarifications based on feedback

pep-0665.rst

@@ -248,6 +248,15 @@ To begin, two key terms should be defined. A **locker** is a tool
 which *produces* a lock file. An **installer** is a tool which
 *consumes* a lock file to install the appropriate dependencies.
 
+The expected information flow to occur if this PEP were accepted, from
+the specification of top-level dependencies to all necessary
+dependencies being installed in a fresh environment, is:
+
+1. Read top-level dependencies from ``pyproject.toml`` (PEP 621).
+2. Generate a lock file via a locker in ``pyproject-lock.d/``.
+3. Install the appropriate dependencies based entirely on information
+   contained in the lock file via an installer.
+
 
 -----
 Goals
@@ -272,7 +281,10 @@ This allows having a single lock file which can work on a myriad of
 platforms and environments when that makes sense. This has been shown
 as a necessary feature by the various tools in the Python packaging
 ecosystem which already have a lock file format (e.g. Pipenv_,
-Poetry_, PDM_).
+Poetry_, PDM_). This can be accomplished by *allowing* (but **not**
+requiring) lockers to defer marker evaluation to the installer, and
+thus permitting the locker to include a wider range of *possible*
+dependencies that the installer has to work with.
 
 The lock file also needs to support *reproducible installations*. If
 one wants to restrict what the lock file covers to a single platform
@@ -649,6 +661,9 @@ Installers MUST implement the
 installed from a lock file inherently originate from a URL and not a
 search of an index by package name and version.
 
+Installers MUST error out if they encounter something they are unable
+to handle (e.g. lack of environment marker support).
+
 
 Example Flow
 ============