update wording and add a simple example

Author: ymqytw

contributors/design-proposals/preserve-order-in-strategic-merge-patch.md

@@ -12,24 +12,38 @@ Ordering has semantic meaning for Environment variables,
 as later environment variables may reference earlier environment variables,
 but not the other way around.
 
-An use case is the environment variables. We don't preserve the order which causes
+One use case is the environment variables. We don't preserve the order which causes
 issue [40373](https://github.com/kubernetes/kubernetes/issues/40373).
 
 ## Proposed Change
 
 Changes are all in strategic merge patch package.
 The proposed solution is similar to the solution used for deleting elements from lists of primitives.
 
-Add to the current patch, a directive containing a list of element keys -
+Add to the current patch, a directive ($setElementOrder) containing a list of element keys -
 either the patch merge key, or for primitives the value. When applying the patch,
-the server we ensure that the relative ordering of elements matches the directive.
+the server ensures that the relative ordering of elements matches the directive.
+
+Here is an simple example:
+
+Suppose we have a type called list. The patch will look like below.
+The order from the parallel list ($setElementOrder/list) will be respected.
+
+```yaml
+$setElementOrder/list:
+- A
+- B
+list:
+- B
+- A
+```
 
 All the items in the server's live list but not in the parallel list will be append to the end of the parallel list.
 The relative order between these appended items are kept.
-If the relative order of live config in the server is different from the order of the parallel list,
-user's patch will always override the order in the server.
+If the relative order of the live config in the server is different from the order of the parallel list,
+the user's patch will always override the order in the server.
 
-The patched list will looks like:
+The patched list will look like:
 
 ```
 mergingList:
@@ -144,8 +158,9 @@ list:
 The new version patch is always a superset of the old version patch.
 The new patch has one additional parallel list which will be dropped by the old server.
 
-The logic for old version patch is still kept,
-so the patch from any arbitrary old clients used to work before will continue to function.
+The new directive is optional.
+Patch requests without the directive will retain the behavior from previous releases.
+This will ensure backward compatibility with old clients.
 
 This change is fully backward compatible.