diff --git a/design-documents/bit-precise-types.rst b/design-documents/bit-precise-types.rst
index 08f77073..96cefa54 100644
--- a/design-documents/bit-precise-types.rst
+++ b/design-documents/bit-precise-types.rst
@@ -306,7 +306,13 @@ B. Double-register sized.
 
 Option ``A`` has the following benefits:
 
+- This would mean that the alignment of a ``_BitInt(128)`` on AArch64 matches
+  that of x86.  This could reduce surprises when writing portable code.
 - Less space used for half of the values of ``N``.
+- Multiplications on large ``_BitInt(N)`` can be logically done on the limbs of
+  size ``M``, which should result in a neater compiler implementation.  E.g.
+  for AArch64 there is a ``SMULH`` which could be used as part of a
+  multiplication on an entire limb.
 
 Option ``B`` has the following benefit:
 
@@ -317,19 +323,30 @@ Option ``B`` has the following benefit:
 - On AArch32 a ``_BitInt(64)`` would have the same alignment and size as an
   ``int64_t``, and on AArch64 a ``_BitInt(128)`` would have the same alignment
   and size as a ``__int128``.
-  These are the largest types defined on the relevant architectures, and
-  correspond to the largest integral Fundamental Data Type defined in the PCS
-  for both platforms.
+- Double-register sized integers match the largest Fundamental Data Types
+  defined in the relevant PCS architectures for both platforms.  We believe
+  that that implementors familiar with the AArch64 ABI would find this mapping
+  less surprising and hence make less mistakes.
 
 The "large" size use-cases we have identified so far are of power-of-two sizes.
-These sizes would not benefit from the positives of either of the options
-presented here.
-
-Hence for "large" sizes we are choosing based on an estimate of which choice is
-more "generally useful".  Our estimate is that the benefits of option ``B`` are
-more generally useful than those from option ``A``.  That is we choose to define
-the size and alignment of ``_BitInt(N > [register-size])`` types by treating
-them "as if" they are an array of double-register sized Fundamental Data Types.
+These sizes would not benefit greatly from the positives of either of the
+options presented here, with the only difference being around the implementation
+of multiplication.
+
+Our estimate is that the benefits of option ``B`` are more useful for sizes
+between register and double-register than those from option ``A``.  This is not
+considered a clear-cut choice, with the main point in favour of option ``A``
+being a smaller difference from x86.
+
+Other variants are available, such as choosing alignment and size based on
+register sized chunks except for the special case of the double-register sized
+_BitInt.  Though such variants can provide a good combination of the properties
+above we judge them to have an extra complexity of definition and associated
+increased likelyhood of mistakes of implementation.
+
+Based on the above reasoning, we would choose to define the size and alignment
+of ``_BitInt(N > [register-size])`` types by treating them "as if" they are an
+array of double-register sized Fundamental Data Types.
 
 Representation in bits
 ----------------------