Updated Design: Persistable Context (markdown)

Design:-Persistable-Context.md

@@ -136,13 +136,16 @@ It executes plugin specific function passed in the argument `command`.
 **Returns** a value that plugin specific function returns. If the plugin return nothing like a `set`, `run` will return `undefined`.
 
 ## Considerations
-* Serializing/Deserializsing JavaScript Objects  
+
+#### Serializing/Deserializsing JavaScript Objects  
+
 `Object` can be stored in current memory context, but most external storage cannot handle `Object` as it is. So Node-RED or plugin should serialize/deserialize `Object`.
 > HU: Persistable Context serializes/deserializes `Objects` using JSON.  
 >     If there are some problems, we will consider how solve those.
 >> DCJ - Agreed for version 1
  
-* Directly accessing Object property   
+#### Directly accessing Object property
+
 A user can directly access Object property in current memory context as following.
 ```JavaScript
 var onj = {"bar":1};
@@ -153,7 +156,7 @@ flow.get("foo.bar"); // return 1
 >     If there are some problems, we will consider how solve those.
 >> DCJ - Agreed for version 1. 
 
-* key name of default storage
+#### Key name of default storage
 
 In the case that `file` is not declared but `default` is declared on contextStorage, if a context data is specified like `$file.count`, Node-RED stores the key name in the default storage.
 In this case, there are two options for storing the key name.
@@ -171,4 +174,6 @@ Cons: If a user uses a same key name for the different storages, name conflictio
 
 My proposal is as follows. Do you agree with this option?
   - Choose the option 2.
-  - Encourage a unique key name by writing it on design note.
+  - Encourage a unique key name by writing it on design note.
+
+> NOL: agreed - fall back to the `default` store, and remove the store name from the key. I think having multiple storage plugins will be rare, so this is an very much an edge case.