diff --git a/debian/changelog b/debian/changelog
index fe13e5a..b4d81f1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 debian-policy (4.5.2.0) UNRELEASED; urgency=medium
 
+  [ Sean Whitton ]
   * Policy: Allow manpages to be included in the dependencies of packages
     Wording: Helmut Grohne <helmut@subdivi.de>
     Seconded: Russ Allbery <rra@debian.org>
@@ -7,6 +8,18 @@ debian-policy (4.5.2.0) UNRELEASED; urgency=medium
     Seconded: Sean Whitton <spwhitton@spwhitton.name>
     Closes: #983657
 
+  [ Russ Allbery ]
+  * Policy: Add new encouraged keyword, make keywords consistent
+    Wording: Russ Allbery <rra@debian.org>
+    Seconded: Sam Hartman <hartmans@debian.org>
+    Seconded: Sean Whitton <spwhitton@spwhitton.name>
+    Closes: #944920
+  * Clarify that no package may install files in /usr/lib64.  The previous
+    wording implied this restriction only applied to 64-bit packages.
+  * Reserve the /etc/rcn.d directories for the init-system-helpers package
+    rather than the sysvinit package, reflecting a change already made in
+    the archive.
+
  -- Sean Whitton <spwhitton@spwhitton.name>  Sun, 28 Feb 2021 14:25:28 -0700
 
 debian-policy (4.5.1.0) unstable; urgency=medium
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index 5fbc0a3..ab04261 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -348,8 +348,8 @@ management tools.
     the user doesn't select anything else. It doesn't include many large
     applications.
 
-    No two packages that both have a priority of ``standard`` or higher
-    may conflict with each other.
+    Two packages that both have a priority of ``standard`` or higher must
+    not conflict with each other.
 
 ``optional``
     This is the default priority for the majority of the archive. Unless
diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index 784bca3..937d0d9 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -362,8 +362,8 @@ adding or removing diversions, package maintainer scripts must provide
 the ``--package`` flag to ``dpkg-divert`` and must not use ``--local``.
 
 All packages which supply an instance of a common command name (or, in
-general, filename) should generally use ``update-alternatives``, so that
-they may be installed together. If ``update-alternatives`` is not used,
+general, filename) should generally use ``update-alternatives`` so that
+they can be installed together. If ``update-alternatives`` is not used,
 then each package must use ``Conflicts`` to ensure that other packages
 are removed. (In this case, it may be appropriate to specify a conflict
 against earlier versions of something that previously did not use
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..fdb1b51 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -72,7 +72,7 @@ Whitespace must not appear inside names (of packages, architectures,
 files or anything else) or version numbers, or between the characters of
 multi-character version relationships.
 
-The presence and purpose of a field, and the syntax of its value may
+The presence and purpose of a field, and the syntax of its value, may
 differ between types of control files.
 
 Field names are not case-sensitive, but it is usual to capitalize the
@@ -571,19 +571,19 @@ The three components here are:
     respect to the ``upstream_version`` is described below. The
     ``upstream_version`` portion of the version number is mandatory.
 
-    The ``upstream_version`` may contain only alphanumerics [#]_ and
+    The ``upstream_version`` must contain only alphanumerics [#]_ and
     the characters ``.`` ``+`` ``-`` ``~`` (full stop, plus, hyphen,
     tilde) and should start with a digit. If there is no
     ``debian_revision`` then hyphens are not allowed.
 
 ``debian_revision``
     This part of the version number specifies the version of the Debian
-    package based on the upstream version. It may contain only
+    package based on the upstream version. It must contain only
     alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
     tilde) and is compared in the same way as the ``upstream_version`` is.
 
     It is optional; if it isn't present then the ``upstream_version``
-    may not contain a hyphen. This format represents the case where a
+    must not contain a hyphen. This format represents the case where a
     piece of software was written specifically to be a Debian package,
     where the Debian package source must always be identical to the
     pristine source and therefore no revision indication is required.
@@ -1065,7 +1065,7 @@ The field can consist of exactly one of the following three items:
  - A space separated list of keywords described below.  These keywords
    must always contain a forward slash, which sets them apart from the
    other possible values of ``Rules-Requires-Root``.  When this list
-   is provided, the builder must provide a `gain root command` (as
+   is provided, the builder must provide a "gain root command" (as
    defined in :ref:`debian/rules and Rules-Requires-Root
    <s-debianrules-gainrootapi>`) *or* pretend that the value was set
    to ``binary-targets``, and both the builder and the package's
@@ -1127,10 +1127,9 @@ In addition to the keywords defined in the next section, each tool or
 package may define keywords within a namespace named after that tool
 or package.  The package or tool is considered to own that namespace.
 
-A tool may use the `gain root command` to do something under
-(fake)root if and only if the tool defines an appropriate keyword in
-its namespace, and the package lists that keyword in
-``Rules-Requires-Root``.
+A tool is permitted to use the "gain root command" to do something under
+(fake)root if and only if the tool defines an appropriate keyword in its
+namespace, and the package lists that keyword in ``Rules-Requires-Root``.
 
 All tools must ignore keywords under namespaces they do not know or
 own.  A tool may emit a warning, or abort with an error, if it finds
diff --git a/policy/ch-customized-programs.rst b/policy/ch-customized-programs.rst
index 747df56..bf8dabb 100644
--- a/policy/ch-customized-programs.rst
+++ b/policy/ch-customized-programs.rst
@@ -139,11 +139,8 @@ web servers and web applications in the Debian system.
 
 3. Access to images
 
-   It is recommended that images for a package be stored in
-   ``/usr/share/images/package`` and may be referred to through an alias
-   ``/images/`` as
-
-   ::
+   Images for a package should be stored in ``/usr/share/images/package``
+   and referred to through an alias ``/images/`` as::
 
        http://localhost/images/package/filename
 
diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
index 4f480ff..f3db835 100644
--- a/policy/ch-docs.rst
+++ b/policy/ch-docs.rst
@@ -141,7 +141,7 @@ separately, as package-doc for example, it may be installed under either
 that path or into the documentation directory for the separate
 documentation package (``/usr/share/doc/package-doc`` in this example).
 However, installing the documentation into the documentation directory
-of the main package is preferred since it is independent of the
+of the main package is encouraged since it is independent of the
 packaging method and will be easier for users to find.
 
 Any separate package providing documentation must still install standard
@@ -157,9 +157,10 @@ documentation should be installed elsewhere, such as under
 ``/usr/share/package/``, and then included via symbolic links in
 ``/usr/share/doc/package``.
 
-``/usr/share/doc/package`` may be a symbolic link to another directory
-in ``/usr/share/doc`` only if the two packages both come from the same
-source and the first package Depends on the second.  [#]_
+``/usr/share/doc/package`` is permitted to be a symbolic link to another
+directory in ``/usr/share/doc`` only if the two packages both come from
+the same source and the first package Depends on the second.  Otherwise,
+``/usr/share/doc/package`` must not be a symbolic link. [#]_
 
 .. _s12.4:
 
@@ -204,9 +205,10 @@ A copy of the file which will be installed in
 ``/usr/share/doc/PACKAGE/copyright`` should be in ``debian/copyright``
 in the source package.
 
-``/usr/share/doc/package`` may be a symbolic link to another directory
-in ``/usr/share/doc`` only if the two packages both come from the same
-source and the first package Depends on the second. These rules are
+``/usr/share/doc/package`` is permitted be a symbolic link to another
+directory in ``/usr/share/doc`` only if the two packages both come from
+the same source and the first package Depends on the second.  Otherwise,
+``/usr/share/doc/package`` must not be a symbolic link. These rules are
 important because ``copyright`` files must be extractable by mechanical
 means.
 
@@ -232,9 +234,8 @@ Machine-readable copyright information
 
 A specification for a standard, machine-readable format for
 ``debian/copyright`` files is maintained as part of the debian-policy
-package. This document may be found in the ``copyright-format`` files in
-the debian-policy package. It is also available from the Debian web
-mirrors at
+package. This document is in the ``copyright-format`` files in the
+debian-policy package. It is also available from the Debian web mirrors at
 https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/.
 
 Use of this format is optional.
diff --git a/policy/ch-files.rst b/policy/ch-files.rst
index 06816ac..b34c183 100644
--- a/policy/ch-files.rst
+++ b/policy/ch-files.rst
@@ -18,7 +18,7 @@ which program will have to be renamed. If a consensus cannot be reached,
 *both* programs must be renamed.
 
 To support merged-\ ``/usr`` systems, packages must not install files in
-both ``/path`` and ``/usr/path``. For example, a package may not install
+both ``/path`` and ``/usr/path``. For example, a package must not install
 both ``/bin/example`` and ``/usr/bin/example``.
 
 If a file is moved between ``/path`` and ``/usr/path`` in revisions of a
@@ -409,8 +409,8 @@ default version will be part of the package distribution, and must not
 be modified by the maintainer scripts during installation (or at any
 other time).
 
-In order to ensure that local changes are preserved correctly, no
-package may contain or make hard links to conffiles. [#]_
+In order to ensure that local changes are preserved correctly, packages
+must not contain or make hard links to conffiles. [#]_
 
 The other way to do it is via the maintainer scripts. In this case, the
 configuration file must not be listed as a ``conffile`` and must not be
@@ -582,8 +582,8 @@ Permissions and owners
 The rules in this section are guidelines for general use. If necessary
 you may deviate from the details below. However, if you do so you must
 make sure that what is done is secure and you should try to be as
-consistent as possible with the rest of the system. You should probably
-also discuss it on ``debian-devel`` first.
+consistent as possible with the rest of the system. You are also
+encouraged to discuss it on ``debian-devel`` first.
 
 Files should be owned by ``root:root``, and made writable only by the
 owner and universally readable (and executable, if appropriate), that is
diff --git a/policy/ch-maintainerscripts.rst b/policy/ch-maintainerscripts.rst
index 707f2d4..709aabf 100644
--- a/policy/ch-maintainerscripts.rst
+++ b/policy/ch-maintainerscripts.rst
@@ -184,7 +184,7 @@ The ``postrm`` script may be called in the following ways:
     removed or replaced. The package whose ``postrm`` is being called
     may have previously been deconfigured and only be "Unpacked", at
     which point subsequent package changes do not consider its
-    dependencies. Therefore, all ``postrm`` actions may only rely on
+    dependencies. Therefore, all ``postrm`` actions must only rely on
     essential packages and must gracefully skip any actions that require
     the package's dependencies if those dependencies are unavailable.
     [#]_
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index abe007f..83b71b1 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -42,14 +42,14 @@ Debian Policy. The following exceptions to the FHS apply:
     and ``/usr/lib{,32}`` is amended, permitting files to instead be
     installed to ``/lib/triplet`` and ``/usr/lib/triplet``, where
     ``triplet`` is the value returned by ``dpkg-architecture -qDEB_HOST_MULTIARCH`` for the architecture of the
-    package. Packages may *not* install files to any triplet path other
+    package. Packages must not install files to any triplet path other
     than the one matching the architecture of that package; for
     instance, an ``Architecture:  amd64`` package containing 32-bit x86
-    libraries may not install these libraries to
+    libraries must not install these libraries to
     ``/usr/lib/i386-linux-gnu``.  [#]_
 
-    No package for a 64 bit architecture may install files in
-    ``/usr/lib64/`` or in a subdirectory of it.
+    Packages must not install files in ``/usr/lib64`` or in a subdirectory
+    of it.
 
     The requirement for C and C++ headers files to be accessible through
     the search path ``/usr/include/`` is amended, permitting files to be
@@ -449,7 +449,7 @@ Instead, they should be placed in a file in ``/etc/default``, which
 typically will have the same base name as the ``init.d`` script. This
 extra file should be sourced by the script when the script runs. It must
 contain only variable settings and comments in POSIX.1-2017 ``sh`` format. It
-may either be a ``conffile`` or a configuration file maintained by the
+must either be a ``conffile`` or a configuration file maintained by the
 package maintainer scripts. See :ref:`s-config-files` for
 more details.
 
@@ -498,8 +498,8 @@ archive or manually create or remove the symbolic links in maintainer
 scripts; you must use the ``update-rc.d`` program instead. (The former
 will fail if an alternative method of maintaining runlevel information
 is being used.) You must not include the ``/etc/rcn.d`` directories
-themselves in the archive either. (Only the ``sysvinit`` package may do
-so.)
+themselves in the archive either. (Only the ``init-system-helpers``
+package is permitted to do so.)
 
 To get the default behavior for your package, put in your ``postinst``
 script::
@@ -531,10 +531,10 @@ package's init script would not start the service until the local
 system administrator changed this to ``DISABLED=no``, or similar.  The
 problem with this approach was that it hides from the init system
 whether or not the daemon should actually be started, which leads to
-inconsistent and confusing behavior: ``service <package> start`` may
+inconsistent and confusing behavior: ``service <package> start`` could
 return success but not start the service; services with a dependency
 on this service will be started even though the service isn't running;
-and init system status commands may incorrectly claim that the service
+and init system status commands could incorrectly claim that the service
 was started.
 
 Note that if your package changes runlevels or priority, you may have to
diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 1211e3e..915d00d 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -143,7 +143,7 @@ Binary Dependencies - ``Depends``, ``Recommends``, ``Suggests``, ``Enhances``, `
 ----------------------------------------------------------------------------------------------
 
 Packages can declare in their control file that they have certain
-relationships to other packages - for example, that they may not be
+relationships to other packages - for example, that they cannot be
 installed at the same time as certain other packages, and/or that they
 depend on the presence of others.
 
@@ -379,7 +379,7 @@ problem. ``Breaks`` should be used
 -  when two packages provide the same file and will continue to do so,
 
 -  in conjunction with ``Provides`` when only one package providing a
-   given virtual facility may be unpacked at a time (see
+   given virtual facility can be unpacked at a time (see
    :ref:`s-virtual`),
 
 -  in other cases where one must prevent simultaneous installation of
diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
index e3db6c1..c91af42 100644
--- a/policy/ch-scope.rst
+++ b/policy/ch-scope.rst
@@ -20,7 +20,7 @@ interface to the package management system with which the developers
 must be conversant.  [#]_
 
 This manual cannot and does not prohibit every possible bug or
-undesirable behaviour.  The fact that something is not forbidden by
+undesirable behaviour.  The fact that something is not prohibited by
 Debian policy does not mean that it is not a bug, let alone that it is
 desirable.  Questions not covered by policy should be evaluated on
 their merits.
@@ -31,21 +31,41 @@ part of Debian policy itself.
 The appendices to this manual are not necessarily normative, either.
 Please see :doc:`ap-pkg-scope` for more information.
 
-In the normative part of this manual, the words *must*, *should* and
-*may*, and the adjectives *required*, *recommended* and *optional*, are
-used to distinguish the significance of the various guidelines in this
-policy document. Packages that do not conform to the guidelines denoted
-by *must* (or *required*) will generally not be considered acceptable
-for the Debian distribution. Non-conformance with guidelines denoted by
-*should* (or *recommended*) will generally be considered a bug, but will
-not necessarily render a package unsuitable for distribution. Guidelines
-denoted by *may* (or *optional*) are truly optional and adherence is
-left to the maintainer's discretion.
-
-These classifications are roughly equivalent to the bug severities
-*serious* (for *must* or *required* directive violations), *minor*,
-*normal* or *important* (for *should* or *recommended* directive
-violations) and *wishlist* (for *optional* items).  [#]_
+In the normative part of this manual, the following terms are used to
+describe the importance of each statement:  [#]_
+
+* The terms *must* and *must not*, and the adjectives *required* and
+  *prohibited*, denote strong requirements. Packages that do not conform
+  to these requirements will generally not be considered acceptable for
+  the Debian distribution. These statements correspond to the *critical*,
+  *grave*, and *serious* bug severities (normally serious). They are
+  collectively called *Policy requirements*.
+
+* The terms *should* and *should not*, and the adjective *recommended*,
+  denote best practices. Non-conformance with these guidelines will
+  generally be considered a bug, but will not necessarily render a package
+  unsuitable for distribution. These statements correspond to bug
+  severities of *important*, *normal*, and *minor*. They are collectively
+  called *Policy recommendations*.
+
+* The adjectives *encouraged* and *discouraged* denote places where Policy
+  offers advice to maintainers, but maintainers are free to follow or not
+  follow that advice. Non-conformance with this advice is normally not
+  considered a bug; if a bug seems worthwhile, normally it would have a
+  severity of *wishlist*. These statements are collectively calld *Policy
+  advice*.
+
+* The term *may* and the adjective *optional* are used to clarify cases
+  where it may otherwise appear that Policy is specifying a requirement or
+  recommendation. In those cases, these words describe decisions that are
+  truly optional and at the maintainer's discretion.
+
+The Release Team can, at their discretion, downgrade a Policy requirement
+to a Policy recommendation for a given release of the Debian distribution.
+This may be done for only a specific package or for the archive as a
+whole. This provision is intended to provide flexibility to balance the
+quality standards of the distribution against the release schedule and the
+importance of making a stable release.
 
 Much of the information presented in this manual will be useful even
 when building a package which is to be distributed in some other way or
@@ -57,6 +77,31 @@ Installer internals
 manual <https://d-i.debian.org/doc/internals/ch03.html>`_ for
 more information about them.
 
+.. [#]
+   Informally, the criteria used for inclusion is that the material meet
+   one of the following requirements:
+
+   Standard interfaces
+       The material presented represents an interface to the packaging
+       system that is mandated for use, and is used by, a significant
+       number of packages, and therefore should not be changed without
+       peer review. Package maintainers can then rely on this interface
+       not changing, and the package management software authors need to
+       ensure compatibility with this interface definition. (Control
+       file and changelog file formats are examples.)
+
+   Chosen Convention
+       If there are a number of technically viable choices that can be
+       made, but one needs to select one of these options for
+       inter-operability. The version number format is one example.
+
+   Please note that these are not mutually exclusive; selected
+   conventions often become parts of standard interfaces.
+
+.. [#]
+   Compare RFC 2119. Note, however, that these words are used in a
+   different way in this document.
+
 .. _s1.2:
 
 New versions of this document
@@ -189,33 +234,8 @@ UTF-8
     useful property of having ASCII as a subset, so any text encoded in
     ASCII is trivially also valid UTF-8.
 
-.. [#]
-   Informally, the criteria used for inclusion is that the material meet
-   one of the following requirements:
-
-   Standard interfaces
-       The material presented represents an interface to the packaging
-       system that is mandated for use, and is used by, a significant
-       number of packages, and therefore should not be changed without
-       peer review. Package maintainers can then rely on this interface
-       not changing, and the package management software authors need to
-       ensure compatibility with this interface definition. (Control
-       file and changelog file formats are examples.)
-
-   Chosen Convention
-       If there are a number of technically viable choices that can be
-       made, but one needs to select one of these options for
-       inter-operability. The version number format is one example.
-
-   Please note that these are not mutually exclusive; selected
-   conventions often become parts of standard interfaces.
-
 Translations
 ------------
 
 When translations of this document into languages other than English
 disagree with the English text, the English text takes precedence.
-
-.. [#]
-   Compare RFC 2119. Note, however, that these words are used in a
-   different way in this document.
diff --git a/policy/ch-sharedlibs.rst b/policy/ch-sharedlibs.rst
index 6cb98b2..69b79d3 100644
--- a/policy/ch-sharedlibs.rst
+++ b/policy/ch-sharedlibs.rst
@@ -89,7 +89,7 @@ be unnecessarily difficult because of file conflicts with the old
 version of the package. When in doubt, always split shared library
 packages so that each binary package installs a single shared library.
 
-Every time the shared library ABI changes in a way that may break
+Every time the shared library ABI changes in a way that could break
 binaries linked against older versions of the shared library, the
 ``SONAME`` of the library and the corresponding name for the binary
 package containing the runtime shared library should change. Normally,
@@ -322,7 +322,7 @@ shared library with only a ``shlibs`` file, the generated dependency
 will require a version of the shared library equal to or newer than the
 version of the last ABI change. This generates unnecessarily restrictive
 dependencies compared to ``symbols`` files if none of the symbols used
-by the package have changed. This, in turn, may make upgrades needlessly
+by the package have changed. This, in turn, could make upgrades needlessly
 complex and unnecessarily restrict use of the package on systems with
 older versions of the shared libraries.
 
@@ -470,9 +470,9 @@ dependency version (for ``shlibs``) files. But special care should be
 taken to update dependency versions when the behavior of a public symbol
 changes. This is easy to neglect, since there is no automated method of
 determining such changes, but failing to update versions in this case
-may result in binary packages with too-weak dependencies that will fail
+could result in binary packages with too-weak dependencies that will fail
 at runtime, possibly in ways that can cause security vulnerabilities. If
-the package maintainer believes that a symbol behavior change may have
+the package maintainer believes that a symbol behavior change could have
 occurred but isn't sure, it's safer to update the version rather than
 leave it unmodified. This may result in unnecessarily strict
 dependencies, but it ensures that packages whose dependencies are
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index edae8c1..4785ece 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -251,7 +251,7 @@ source files in a package, as far as is reasonably possible.  [#]_
 Restrictions on objects in source packages
 ------------------------------------------
 
-The source package may not contain any hard links,  [#]_ device special
+The source package must not contain any hard links,  [#]_ device special
 files, sockets or setuid or setgid files.. [#]_
 
 .. _s-debianrules:
@@ -307,7 +307,7 @@ commands it invokes options that cause them to produce verbose output.
 For example, the build target should pass ``--disable-silent-rules``
 to any configure scripts.  See also :ref:`s-binaries`.
 
-For packages in the main archive, no required targets may attempt
+For packages in the main archive, required targets must not attempt
 network access, except, via the loopback interface, to services on the
 build host that have been started by the build.
 
@@ -659,14 +659,15 @@ substitutions, including the format of ``debian/substvars``.
 
 .. _s-debianwatch:
 
-Optional upstream source location: ``debian/watch``
----------------------------------------------------
+Upstream source location: ``debian/watch``
+------------------------------------------
 
-This is an optional, recommended configuration file for the ``uscan``
-utility which defines how to automatically scan ftp or http sites for
-newly available updates of the package. This is also used by some Debian
-QA tools to help with quality control and maintenance of the
-distribution as a whole.
+This is a configuration file for the ``uscan`` utility which defines how
+to automatically scan ftp or http sites for newly available updates of the
+package. This is also used by some Debian QA tools to help with quality
+control and maintenance of the distribution as a whole. If the upstream
+source of the package is available via a mechaism that ``uscan``
+understands, including this configuration file is recommended.
 
 If the upstream maintainer of the software provides OpenPGP signatures
 for new releases, including the information required for ``uscan`` to
@@ -798,14 +799,13 @@ the upstream tarball.  In order to satisfy the DFSG for packages in
 2. include a copy of the sources in the ``debian/missing-sources``
    directory.
 
-There is an optional convention to organise the contents of
-``debian/missing-sources`` in the following way.  For a sourceless
-file ``foo`` in the subdirectory ``bar`` of the upstream tarball,
-where the source of ``foo`` has extension ``baz``, the source is to be
-located at ``debian/missing-sources/bar/foo.baz``.  For example,
-according to this convention, the C source code of an executable
-``checksum/util`` is to be located at
-``debian/missing-sources/checksum/util.c``.
+Package maintainers may optionally use the following convention to
+organize the contents of ``debian/missing-sources``: for a sourceless file
+``foo`` in the subdirectory ``bar`` of the upstream tarball, where the
+source of ``foo`` has extension ``baz``, place the source at
+``debian/missing-sources/bar/foo.baz``. For example, according to this
+convention, the C source code of an executable ``checksum/util`` would be
+located at ``debian/missing-sources/checksum/util.c``.
 
 Vendor-specific patch series
 ----------------------------
diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index 00e8090..15588fa 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -44,6 +44,10 @@ Version 4.5.2
 
 Unreleased.
 
+9.1.1
+    No package is allowed to install files in ``/usr/lib64/``. Previously,
+    this prohibition only applied to packages for 64-bit architectures.
+
 12.1
     Manual pages may be included in dependencies, not only in the packages
     containing the things they document.
