refactor: address a few bits of feedback

Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>

Author: henryiii

peps/pep-0808.rst

@@ -198,7 +198,7 @@ example).
 Example: licenses
 -----------------
 
-As another example, a package could specify it's license(s):
+As another example, a package could specify its license(s):
 
 .. code-block:: toml
 
@@ -275,12 +275,10 @@ The fields that are arrays or tables with arbitrary entries are:
 To add items, users must opt-in by listing the field in ``dynamic``; without
 that, the metadata continues to be entirely static.
 
-A backend SHOULD warn if a field is specified and it does not know how to
-extend that field, to protect against possible user error, and MAY throw an
-error instead. It should be noted, however, that mistakenly adding a field to
-the ``dynamic`` array is not a serious mistake, as it only limits the ability
-of a static tool to ensure completeness, so it is up to the discretion of the
-backend if this warrants an error.
+A backend SHOULD error if a field is specified and it does not support
+extending that field, to protect against possible user error. We recommend
+being as strict as possible to avoid unnecessary entries in the ``dynamic``
+list.
 
 Static analysis tools, when detecting a field is both specified and in the
 ``project.dynamic`` array, SHOULD assume the field is incomplete, allowing for
@@ -344,6 +342,10 @@ field. An example of such an update for the license field:
 
 * When also listed in ``dynamic``: Can be extended with ``AND``
 
+It should also be noted that specifying something in dynamic will require any
+tool that requires the full metadata to invoke the backend even if it is
+partially statically specified, so it should not be used unless necessary.
+
 
 Rejected Ideas
 ==============