I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3.
You need an objective way to sort this out.
I guess OP would say B should
never witness both A2 and A2+, users are supposed to get
enough witness for A chain before considering a transaction confirmed.
That might work for an individual user, but if different users see a different state due to latency, you're back at square 1. There has to be some objective way of resolving this; either you have to adopt the synchronous swilrds hashgrid consensus(1), or you need to adopt something with a probabilistic finality like the tangle(2), or T.E.T.O(3).