The current APPEND implementation may lead to out of order values

[devfire]

Under the following the scenario:

1. client A tries to append a value to the existing key
2. client A gets the current value first to see if it exists
3. meanwhile, client B sets a different value for the same key
4. client A appends the string to the now old value of same key
5. client B value will be lost <-- problem!

Basically, APPEND needs to be created as a basic SET actor primitive, not a higher order function on top of the existing primitives.