Mention the limitation of the current "__extra__" approach.

I left out the rewrite to other proposed syntax such as using
"OtherFields[]" with an arbitrary key before there is sufficient
discussion on the alternatives available to us.

Signed-off-by: Zixuan James Li <[email protected]>

Author: PIG208

peps/pep-0728.rst

@@ -531,13 +531,22 @@ checking logic:
       achieve this using `total=False`, which follows from existing rules for
       expanded callables.
 
+Alternatives to the ``__extra__`` Magic Field
+---------------------------------------------
+
+As it was pointed out in the PEP 705 review comment [11]_, ``__extra__``
+as a field has some disadvantages, including not allowing "__extra__"
+as a regular key, requiring special-handling to disallow ``Required`` 
+and ``NotRequired``. There could be some better alternatives to this
+without the above mentioned issues.
+
 Backwards Compatibility
 =======================
 
-Dunder attributes like ``__extra__`` are reserved for stdlib, we need not
-concerned about using it in this proposal. If the proposal is accepted, neither
-``__required_keys__`` and ``__optional_keys__`` should include ``__extra__`` in
-runtime.
+While dunder attributes like ``__extra__`` are reserved for stdlib, it is still
+a limitation that ``__extra__`` is no longer usable as a regular key. If the
+proposal is accepted, neither ``__required_keys__`` and ``__optional_keys__``
+should include ``__extra__`` in runtime.
 
 Because this is a type-checking feature, it can be made available to older
 versions as long as the type checker supports it without requiring imports from
@@ -610,6 +619,7 @@ References
 .. [8] https://www.typescriptlang.org/docs/handbook/2/objects.html#index-signatures
 .. [9] https://github.com/microsoft/TypeScript/issues/17867
 .. [10] https://github.com/python/mypy/pull/15612#discussion_r1298300340
+.. [11] https://discuss.python.org/t/pep-705-typeddict-read-only-and-other-keys/36457/6
 
 Acknowledgments
 ================