Add a new section and fix links.

Author: ZeroIntensity

peps/pep-0797.rst

@@ -105,10 +105,10 @@ other areas of CPython, or in third-party libraries:
   (:c:func:`PyUnstable_Object_EnableDeferredRefcount`), but that has the downside
   of damaging single-threaded performance.
 - Immortality can help memory usage by avoiding copy-on-write operations in
-  child processes. Instagram has been `doing this in Cinder <pep-797-cinder>`_
-  for years, and it would be nice to let CPython also take advantage of it.
+  child processes. Instagram has been `doing this in Cinder`_ for years,
+  and it would be nice to let CPython also take advantage of it.
 
-.. _pep-797-cinder: https://engineering.fb.com/2023/08/15/developer-tools/immortal-objects-for-python-instagram-meta/
+.. _doing this in Cinder: https://engineering.fb.com/2023/08/15/developer-tools/immortal-objects-for-python-instagram-meta/
 
 Motivation
 ==========
@@ -119,13 +119,12 @@ Immortal Objects Must Remain in CPython
 In the past, the main pushback to exposing APIs for immortality is that
 it's exposing an implementation detail, and would force CPython to keep
 immortality forever. Unfortunately, we've already reached that point: too
-many users, and `CPython itself <_pep-797-omitting-immortals>`_, omit
-reference counting for known immortal objects, such as :c:data:`Py_None`.
-Since there's no good way to deprecate that, CPython will always need some
-form of immortality to retain compatibility. That said, this proposal still
-keeps all new APIs as unstable.
+many users, and `CPython itself`_, omit reference counting for known immortal
+objects, such as :c:data:`Py_None`. Since there's no good way to deprecate
+that, CPython will always need some form of immortality to retain
+compatibility. That said, this proposal still keeps all new APIs unstable.
 
-.. _pep-797-omitting-immortals: https://github.com/python/cpython/issues/103906
+.. _CPython itself: https://github.com/python/cpython/issues/103906
 
 Objects Cannot be Directly Shared Between Interpreters
 ******************************************************
@@ -175,6 +174,17 @@ In doing so, an object will release its memory back to CPython's object allocato
 allocator is per-interpreter, so it is unsafe to try to release an object's
 memory in an interpreter different from the one that created it.
 
+
+Immortality is a Powerful Tool to Wield
+***************************************
+
+In general, immortal objects seem to have a lot of applications that aren't
+immediately clear. For example, `Nanobind used immortal objects`_
+in its original :term:`free threading` implementation. It seems like it would
+have interesting use-cases for many places outside of CPython.
+
+.. _Nanobind used immortal objects: https://github.com/wjakob/nanobind/pull/695
+
 Specification
 =============
 
@@ -233,7 +243,7 @@ This PEP introduces two new semi-public APIs for making an object immortal:
    it's very unlikely that a type doesn't follow it:
 
    * The object must be allocated under either the "object" or "memory" allocator
-     domains. See :ref:`Allocator Domains <allocator-domains>` for more information.
+     domains. See :ref:`Allocator Domains <python:allocator-domains>` for more information.
      Default values of :c:member:`~PyTypeObject.tp_alloc` always use the object
      allocator.
    * All :term:`strong references <strong reference>` released in the object's
@@ -289,7 +299,7 @@ or in tests) will now break if they are made immortal, because the reference
 count of an object will unexpectedly not change.
 
 In one of the 3.14 alphas, this rule about reference counting was
-`brought up <pep-797-limited-refcount>`_ for clarification by a user of the
+`brought up`_ for clarification by a user of the
 limited C API. From that post, it's clear that reference count numbers are
 an implementation detail:
 
@@ -303,7 +313,7 @@ that reference counts are unstable:
     well-defined values; the number of references to an object, and how that
     number is affected by Python code, may be different between versions.
 
-.. _pep-797-limited-refcount: https://discuss.python.org/t/72006
+.. _brought up: https://discuss.python.org/t/72006
 
 Destructors Must Use ``tp_finalize``
 ------------------------------------
@@ -528,7 +538,7 @@ Preventing Reference Cycle UAFs
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Before any destruction of immortal objects starts to happen,
-`deferred memory deletion <Deferred Memory Deletion>`_ needs to be enabled.
+deferred memory deletion needs to be enabled.
 This is because the garbage collector doesn't manually call
 :c:member:`~PyTypeObject.tp_dealloc`, but instead it relies on
 :c:member:`~PyTypeObject.tp_clear` to get reference counts to zero.