PEP 735: move project includes to "deferred ideas"

Move the sections on `[project]` includes and `[build-system]`
includes to Deferred Ideas, as an added section.

Restore the removed use case for this, as a subsection of one of these
Deferred Ideas.

Also, per suggestion, remove an unnecessary phrase ("defined below" in
a context where it is _immediately_ followed by the relevant
section).

peps/pep-0735.rst

@@ -242,8 +242,7 @@ Strings in requirement lists must be valid
 `Dependency Specifiers <https://packaging.python.org/en/latest/specifications/dependency-specifiers/>`__,
 as defined in :pep:`508`.
 
-Tables in requirement lists must be valid Dependency Object Specifiers,
-defined below.
+Tables in requirement lists must be valid Dependency Object Specifiers.
 
 Dependency Object Specifiers
 ----------------------------
@@ -704,6 +703,9 @@ has impacts on high-level tools like IDEs and Dependabot, which cannot support
 deep integration with these Dependency Groups. (For example, at time of writing
 Dependabot will not flag dependencies which are pinned in ``tox.ini`` files.)
 
+Deferred Ideas
+==============
+
 Why not support Dependency Group Includes in ``[project.dependencies]`` or ``[project.optional-dependencies]``?
 ---------------------------------------------------------------------------------------------------------------
 
@@ -720,18 +722,56 @@ backends, SBOM generators, and dependency analyzers are implicated by a change t
 ``[project]`` but may continue to operate as-is in the presence of a new (but
 unconnected) ``[dependency-groups]`` table.
 
-Separately from the above concern, the usage modes for
-``[dependency-groups]`` which rely upon inclusion from the ``[project]`` table
-encourage package maintainers to move package metadata from the currently
-standardized location into a newly standardized location. This has a
-negative effect on the simplicity of the mostly static ``pyproject.toml`` metadata
-definition laid out in :pep:`621`.
+Separately from the above concern, allowing inclusion of dependency groups from the
+``[project]`` table encourages package maintainers to move dependency metadata out
+of the current standard location.
+This complicates static ``pyproject.toml`` metadata and conflicts with the goal of
+:pep:`621` to store dependency metadata in a single location.
 
 Finally, exclusion of ``[project]`` support from this PEP is not final. The
 use of includes from that table, or an inclusion syntax from
 ``[dependency-groups]`` into ``[project]``, could be introduced by a future
 PEP and considered on its own merits.
 
+Use Cases for Dependency Group Includes From ``[project]``
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+Although deferred in this PEP, allowing includes from the ``[project]``
+table would address several use cases.
+
+In particular, there are cases in which package developers would like to
+install only the dependencies of a package, without the package itself.
+
+For example:
+
+* Specify different environment variables or options when building dependencies
+  vs when building the package itself
+
+* Creating layered container images in which the dependencies are isolated from
+  the package being installed
+
+* Providing the dependencies to analysis environments (e.g., type checking)
+  without having to build and install the package itself
+
+For an example of the last case, consider the following sample
+``pyproject.toml``:
+
+.. code-block:: toml
+
+    [project]
+    dependencies = [{include = "runtime"}]
+    [optional-dependencies]
+    foo = [{include = "foo"}]
+    [dependency-groups]
+    runtime = ["a", "b"]
+    foo = ["c", "d"]
+    typing = ["mypy", {include = "runtime"}, {include = "foo"}]
+
+In this case, a ``typing`` group can be defined, with all of the package's
+runtime dependencies, but without the package itself. This allows uses of the
+``typing`` Dependency Group to skip installation of the package -- not only is
+this more efficient, but it may reduce the requirements for testing systems.
+
 Why not support Dependency Group Includes in ``[build-system.requires]``?
 -------------------------------------------------------------------------
 
@@ -742,9 +782,13 @@ Given that we will not allow for ``[project]`` usage of Dependency Groups,
 There are fewer theoretical usages for build requirements specified in a group
 than package requirements. Additionally, the impact of such a change implicates
 :pep:`517` frontend, which would need to support Dependency Groups in order to
-prepare a build environment. Support in the ``[project]`` table is less
-impactful than this, with stronger motivation, and is still considered out of
-scope.
+prepare a build environment.
+
+Compared with changes to ``[project.dependencies]`` and
+``[project.optional-dependencies]``, changing the behaviors of
+``[build-system.requires]`` is higher impact and has fewer potential uses.
+Therefore, given that this PEP declines to make changes to the ``[project]``
+table, changing ``[build-system]`` is also deferred.
 
 .. _prior_art: