diff --git a/peps/pep-0718.rst b/peps/pep-0718.rst
index 13b4ccc1f9c..d9fbccff3e0 100644
--- a/peps/pep-0718.rst
+++ b/peps/pep-0718.rst
@@ -201,10 +201,56 @@ The following code snippet would fail at runtime without this change as
 Interactions with ``@typing.overload``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Overloaded functions should work much the same as already, since they have no effect on
-the runtime type. The only change is that more situations will be decidable and the
-behaviour/overload can be specified by the developer rather than leaving it to ordering
-of overloads/unions.
+Overloaded functions should work much the same as they already do, since they do not
+affect the runtime type. Explicit specialisation will restrict the set of available
+overloads.
+
+.. code-block:: python
+
+   @overload
+   def make[T](x: T) -> T: ...
+   @overload
+   def make(x: str, y: str) -> tuple[int, int]: ...
+
+   reveal_type(make[int](1))             # type is int
+   reveal_type(make[int]("foo", "bar"))  # Invalid: no overload for `make[int](x: str, y: str)` found, a similar overload exists but explicit specialisation prevented its use
+
+Functions Parameterized by ``TypeVarTuple``\ s
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Currently, type checkers disallow the use of multiple ``TypeVarTuple``\s in their
+generic parameters; however, it is currently valid to have a function as such:
+
+.. code-block:: python
+
+   def foo[*T, *U](bar: Bar[*T], baz: Baz[*U]): ...
+   def spam[*T](bar: Bar[*T]): ...
+
+This PEP does not allow functions like ``foo`` to be subscripted, for the same reason
+as defined in :pep:`PEP 646<646#multiple-type-variable-tuples-not-allowed>`.
+
+.. code-block:: python
+
+   foo[int, str, bool, complex](Bar(), Baz())  # Invalid: cannot determine which parameters are passed to *T and *U. Explicitly parameterise the instances individually
+   spam[int, str, bool, complex](Bar())        # OK
+
+Binding Rules
+^^^^^^^^^^^^^
+Method subscription (including ``classmethods``, ``staticmethods``, etc.) should only
+have access to their function's type parameter and not the enclosing class's.
+Subscription should follow the rules specified in :pep:`PEP 696<696#binding-rules>`;
+methods should bind type parameters on attribute access.
+
+.. code-block:: python
+
+   class C[T]:
+       def method[U](self, x: T, y: U): ...
+       @classmethod
+       def cls[U](cls, x: T, y: U): ...
+
+   C[int].method[str](0, "")  # OK
+   C[int].cls[str](0, "")     # OK
+   C.cls[int, str](0, "")     # Invalid: too many type parameters
+   C.cls[str](0, "")          # OK, T is ideally bound to int here though this is open for type checkers to decide
 
 Backwards Compatibility
 -----------------------