add a section and one alternitive

Author: ymqytw

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

@@ -55,6 +55,49 @@ mergingList:
 - otherItemN /
 ```
 
+### When $setElementOrder is not present and patching a list
+
+The new directive $setElementOrder is optional.
+The new server applying a patch request without the directive will be
+a best-effort operation to keep the order of elements that are already in the list:
+
+For changes and deletions, the server will just merge the change without sorting them.
+So the items in the list will retain the order.
+
+For additions, the items will be appended to the end of the list.
+
+So it changes a little from previous releases, but is still fully backward compatible with old clients.
+
+Examples where A and C have been changed, B has been deleted and D has been added.
+
+Patch:
+
+```yaml
+list:
+- A'
+- $patch: delete
+  B
+- D
+```
+
+Live:
+
+```yaml
+list:
+- C
+- B
+- A
+```
+
+Result:
+
+```yaml
+list:
+- C
+- A
+- D
+```
+
 ### `$setElementOrder` may contain elements not present in the patch list
 
 The $setElementOrder value may contain elements that are not present in the patch
@@ -158,11 +201,10 @@ 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 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.
+As mentioned [above](#when-setelementorder-is-not-present-and-patching-a-list),
+the new directive is optional.
+Patch requests without the directive will change a little,
+but still be fully backward compatible.
 
 ### kubectl
 If an old kubectl sends a old patch to a new server, the server will not preserve the order which behave as an old server.
@@ -329,6 +371,74 @@ finalizers:
 
 # Alternative Considered
 
+# 1. Use the patch list to set order
+
+## Proposed Change
+
+This approach can considered as merging the parallel list and patch list into one single list.
+
+For list of maps, the patch list will have all entries that are
+either a map that contains the mergeKey and other changes
+or a map that contains the mergeKey only.
+
+For list of primitives, the patch list will be the same as the list in users' local config.
+
+## Reason of Rejection
+
+It cannot work correctly in the following concurrent writers case,
+because PATCH in k8s doesn't use optimistic locking, so the following may happen.
+
+Live config is:
+
+```yaml
+list:
+- mergeKey: a
+  other: A
+- mergeKey: b
+  other: B
+- mergeKey: c
+  other: C
+```
+
+Writer foo first GET the object from the server.
+It wants to delete B, so it calculate the patch and is about to send it to the server:
+
+```yaml
+list:
+- mergeKey: a
+- mergeKey: b
+  $patch: delete
+- mergeKey: c
+```
+
+Before foo sending the patch to the server,
+writer bar GET the object and it want to update A.
+
+Patch from bar is:
+
+```yaml
+list:
+- mergeKey: a
+  other: A'
+- mergeKey: b
+- mergeKey: c
+```
+
+After the server first applying foo's patch and then bar's patch,
+the final result will be wrong.
+Because entry b has been recreated which is not desired.
+
+```yaml
+list:
+- mergeKey: a
+  other: A
+- mergeKey: b
+- mergeKey: c
+  other: C
+```
+
+# 2. Use $position Directive
+
 ## Proposed Change
 
 Use an approach similar to [MongoDB](https://docs.mongodb.com/manual/reference/operator/update/position/).