diff --git a/proposals/P0009.rst b/proposals/P0009.rst
index 432dc64..987700f 100644
--- a/proposals/P0009.rst
+++ b/proposals/P0009.rst
@@ -990,7 +990,7 @@ verbose and unwieldy.
 ..
 
 The preferred mechanism is compact, is intuitive,
-LEWG has staw-polled strong preference,
+LEWG has straw-polled strong preference,
 and users have voiced strong expressed preference.
 
 .. code-block:: c++
@@ -1131,12 +1131,12 @@ Subspan behavior:
   // given U.rank() == 4
   void foo( mdspan< DataType , Properties ... > const & U )
   {
-    auto V = subspan( U , make_pair(1,U.extent(0)-1) , 1 , make_pair(2,U.extent(2)-2 );
+    auto V = subspan( U , make_pair(1,U.extent(0)-1) , 1 , make_pair(2,U.extent(2)-2, 2);
     assert( V.extent(0) == U.extent(0) - 2 );
-    assert( V.extent(1) == U.extent(2) - 2 );
-    assert( & V(0,0) == U(1,1,2,2) );
-    assert( & V(1,0) == U(2,1,2,2) );
-    assert( & V(0,1) == U(1,1,3,2) );
+    assert( V.extent(1) == U.extent(2) - 4 );
+    assert( & V(0,0) == & U(1,1,2,2) );
+    assert( & V(1,0) == & U(2,1,2,2) );
+    assert( & V(0,1) == & U(1,1,3,2) );
   }
 
 ..
@@ -1150,10 +1150,10 @@ ISOCPP issue: https://issues.isocpp.org/show_bug.cgi?id=80
 - **P0122 : span: bounds-safe views for sequences of objects**
   The ``mdspan`` codomain concept of *span* is well-aligned with this paper.
 - **P0367 : Accessors**
-  The P0367 Accessors proposal includes polymorphic mechanisms for 
+  The P0367 Accessors proposal includes polymorphic mechanisms for
   accessing the memory an object or span of objects.
   The ``Properties...`` extension point in this proposal is intended
-  to include such memroy access properties.
+  to include such memory access properties.
 - **P0454 : Wording for a Minimal ``mdspan``** (withdrawn)
 - **P0546 : Preparing ``span`` for the future**
 - **P0567 : Asynchronous Managed Pointer for Hetergeneous ...**
diff --git a/proposals/P0331.rst b/proposals/P0331.rst
index f38397e..1283cbd 100644
--- a/proposals/P0331.rst
+++ b/proposals/P0331.rst
@@ -144,10 +144,10 @@ For example, a one-dimensional array is passed to a function as follows.
 The *const-ness* of an ``array_ref`` is analogous to the *const-ness*
 of a pointer.
 A ``const array_ref<D>`` is similar to a const-pointer in that the ``array_ref``
-may not be modifid but the referenced extent of memory may be modified.
+may not be modified but the referenced extent of memory may be modified.
 A ``array_ref<const D>`` is similar to a pointer-to-const in that the
 referenced extent of memory may not be modified. These are the same *const-ness*
-semantics of ``unique_ptr`` and ``shared_ptr``. 
+semantics of ``unique_ptr`` and ``shared_ptr``.
 
 The ``T[]`` syntax has precedence in the standard; ``unique_ptr`` supports this
 syntax to denote a ``unique_ptr`` which manages the lifetime of a dynamically
@@ -246,7 +246,7 @@ Preferred Syntax
 ------------------------------------------------------------------------------
 
 We prefer the following concise and intuitive syntax for arrays
-with multiple implict dimensions.
+with multiple implicit dimensions.
 
 .. code-block:: c++
 
@@ -404,8 +404,8 @@ through tiles as *subarray* of the array.
 
 ..
 
-Note that a tiled layout mapping is irregular and if padding is 
-required to align with tile boundarries then the span will exceed the size.
+Note that a tiled layout mapping is irregular and if padding is
+required to align with tile boundaries then the span will exceed the size.
 A customized layout mapping will have slightly different requirements
 depending on whether the layout is regular or irregular.
 
@@ -423,7 +423,8 @@ A member access array bounds checking array property allows
 the selective injection of array bounds checking and removes
 the need for special compiler support.
 A high quality implementation of bounds checking would output the
-array bounds, multi-index, and traceback of where the array bounds violation occured.
+array bounds, multi-index, and traceback of where the array bounds
+violation occurred.
 
 .. code-block:: c++
 
@@ -505,7 +506,7 @@ The ``subarray`` function returns ``array_ref<`` *deduced...* ``>``.
 The return type is deduced from the input ``array_ref`` and the slicing argument pack.
 The deduction rules must be defined to insure correctness and
 should be defined for performance.
-For example, a simple rule wuld define the returned type to always
+For example, a simple rule would define the returned type to always
 have a strided layout.  While correct there are many use cases
 where a better performing layout can be deduced.
 
@@ -517,7 +518,7 @@ Example Usage in an 8th Order Finite Difference Stencil
 ------------------------------------------------------------------------
 
 The subarray interface provides a powerful mechanism for accessing
-3-dimensional data in numerical kernels in a fashion which utilizes performant
+3-dimensional data in numerical kernels in a fashion which utilizes efficient
 memory access patterns and is amenable to compiler-assisted vectorization.
 
 The following code is an example of a typical finite difference stencil which