diff --git a/peps/pep-0757.rst b/peps/pep-0757.rst
index 5fe1ba52dc6..12b967c1bbf 100644
--- a/peps/pep-0757.rst
+++ b/peps/pep-0757.rst
@@ -388,23 +388,6 @@ There is no impact on the backward compatibility, only new APIs are
 added.
 
 
-Open Questions
-==============
-
-* Should we add *digits_order* and *endianness* members to :data:`sys.int_info`
-  and remove :c:func:`PyLong_GetNativeLayout()`?  The
-  :c:func:`PyLong_GetNativeLayout()` function returns a C structure
-  which is more convenient to use in C than :data:`sys.int_info` which uses
-  Python objects.
-* Currently, all required information for :class:`int` import/export is
-  already available via :c:func:`PyLong_GetInfo()` or :data:`sys.int_info`.
-  Native endianness of "digits" and current order of digits (least
-  significant digit first) --- is a common denominator of all libraries
-  for arbitrary precision integer arithmetic.  So, shouldn't we just remove
-  from API both :c:struct:`PyLongLayout` and :c:func:`PyLong_GetNativeLayout()` (which
-  is actually just a minor convenience)?
-
-
 Rejected Ideas
 ==============
 
@@ -426,6 +409,46 @@ If later there are use cases for arbitrary layouts, new APIs can be
 added.
 
 
+Don't add :c:func:`PyLong_GetNativeLayout` function
+---------------------------------------------------
+
+Currently, most required information for :class:`int` import/export is already
+available via :c:func:`PyLong_GetInfo()` (and :data:`sys.int_info`).  We also
+can add more (like order of digits), this interface doesn't poses any
+constraints on future evolution of the :c:type:`PyLongObject`.
+
+The problem is that the :c:func:`PyLong_GetInfo()` returns a Python object,
+:term:`named tuple`, not a convenient C structure and that might distract
+people from using it in favor e.g. of current semi-private macros like
+:c:macro:`!PyLong_SHIFT` and :c:macro:`!PyLong_BASE`.
+
+
+Provide mpz_import/export-like API instead
+------------------------------------------
+
+The other approach to import/export data from :class:`int` objects might be
+following: expect, that C extensions provide contiguous buffers that CPython
+then exports (or imports) the *absolute* value of an integer.
+
+API example::
+
+    struct PyLongLayout {
+        uint8_t bits_per_digit;
+        uint8_t digit_size;
+        int8_t digits_order;
+    };
+
+    size_t PyLong_GetDigitsNeeded(PyLongObject *obj, PyLongLayout layout);
+    int PyLong_Export(PyLongObject *obj, PyLongLayout layout, void *buffer);
+    PyLongObject *PyLong_Import(PyLongLayout layout, void *buffer);
+
+This might work for the GMP, as this it has :c:func:`!mpz_limbs_read()` and
+:c:func:`!mpz_limbs_write()` functions, that can provide required "buffers".
+
+The major drawback of this approach is that it's much more complex on the
+CPython side (i.e. actual conversion between different layouts).
+
+
 Discussions
 ===========