Add FAQ entries explaining why project name and version are required at session creation.

Author: warsaw

peps/pep-0694.rst

@@ -703,11 +703,9 @@ The request looks like:
 Besides the standard ``meta`` key, the request JSON has the following additional keys:
 
 ``filename`` (**required**)
-    The name of the file being uploaded.  The filename **MUST** conform to either the `source distribution
-    file name specification
-    <https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-file-name>`_
-    or the `binary distribution file name convention
-    <https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-name-convention>`_.
+    The name of the file being uploaded.  The filename **MUST** conform to either the
+    `source distribution file name specification <sdist-filename-spec_>`_
+    or the `binary distribution file name convention <wheel-filename-spec_>`_.
     Indexes **SHOULD** validate these file names at the time of the request, returning a ``400 Bad Request``
     error code and an RFC 9457 style error body, as described in the :ref:`session-errors` section when the
     file names do not conform.
@@ -1274,6 +1272,57 @@ index could define :ref:`index-specific metadata <index-specific-metadata>` to,
 an organization of which the publisher is a member, to own the new project.
 
 
+Why is the project name required when creating a publishing session?
+--------------------------------------------------------------------
+
+The project name is required at session creation because index permissions are fundamentally
+tied to project ownership.  Users have roles and permissions on specific projects, and these
+permissions must be verified before any uploads can proceed.
+
+Requiring the project name upfront provides several benefits:
+
+**Immediate permission validation**: The server can verify that the authenticated user has
+upload permission for the project at session creation time, failing fast with a clear error
+rather than discovering permission issues after files have been uploaded.
+
+**Simplified error handling**: If a session could span multiple projects, a permission failure
+on one project mid-upload would leave the session in a complex partial state.  With a single
+project per session, permission errors are unambiguous.
+
+**Trusted Publisher compatibility**: Indexes like PyPI support `Trusted Publishers
+<https://docs.pypi.org/trusted-publishers/>`__ where OIDC tokens are scoped to specific projects.
+A single-project session aligns naturally with this authentication model.
+
+**Quota enforcement**: Projects may have different upload quotas or size limits.  Validating
+these constraints upfront is simpler when the project is known at session creation.
+
+**Atomic release semantics**: A publishing session represents an atomic release of a single
+project version.  Allowing multiple projects would fundamentally change this model and
+complicate the definition of what "publish" means for a session.
+
+
+Why is the version required when creating a publishing session?
+---------------------------------------------------------------
+
+The version is required at session creation to establish a validation contract before any file
+uploads begin.  Since artifact filenames encode the version (per the `sdist <sdist-filename-spec_>`_
+and `wheel <wheel-filename-spec_>`_ filename specifications), the server can validate that all
+uploaded files match the declared version.
+
+This design enables deterministic behavior with :ref:`parallel uploads <client-recommendations>`.
+If the version were optional and inferred from the first uploaded file, a race condition would
+occur when multiple files are uploaded in parallel: whichever upload the server processes first
+would "win" and establish the version, causing other uploads with mismatched versions to fail
+non-deterministically.
+
+By requiring the version upfront, all parallel uploads validate against the same declared version.
+A file with a mismatched version always fails, regardless of upload timing or order.
+
+For :ref:`name registration <publishing-session-create>` where no artifacts are uploaded, the
+version can be any valid placeholder (e.g., ``"0.0.0a0"``) since it is ignored when no files are
+included in the session.
+
+
 Open Questions
 ==============
 
@@ -1311,6 +1360,9 @@ as experience is gained operating Upload 2.0.
 .. [#fn-immutable] Published files may still be yanked (i.e. :pep:`592`) or `deleted
                    <https://pypi.org/help/#file-name-reuse>`__ as normal.
 
+.. _sdist-filename-spec: https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-file-name
+.. _wheel-filename-spec: https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-name-convention
+
 
 Change History
 ==============
@@ -1323,6 +1375,7 @@ Change History
     endpoints are now used only for ``GET`` (status) and ``DELETE`` (cancel) operations.
   * Add non-normative :ref:`Recommendations for Client Implementers <client-recommendations>` section
     with suggested UX patterns for tools like twine, uv, and GitHub Actions.
+  * Add FAQ entries explaining why project name and version are required at session creation.
 
 * `06-Dec-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/35>`__