@jdubray thanks, I'm very interested of your opinion. In general my intention was to provide much simpler implementation of 'predicable' state than redux/flux or sam. This solution is not inline with SAM (or any other arch). Firstly I want to know that such solution creates really predicable state, and is covering all cases (async, nap, ...), secondary I want to compare this with existing solutions :)
I used Proxies because this was simplest/cheapest way to implement middlewares pattern, but this can be done in totally implicite way.
Setter (and getter) is just a function (can be pure), nothing more. Inn my example action do not creates setter but is propose next state to model, which will be accepted/rejected/decorated by middleware (which is setter).
What is key point here is that there is one contract between view-model-action which is a state (this can be advantage eg. when you have bff, or disadvantage), and the second is that actions do not have to know anything about how the model process proposal.