I thought about the balance and in-out models a bit more.
I may have changed my mind about the balance model, but i may be completely wrong.

Assume we have multiple networks with relatively high bandwidth internal and very low bandwidth and unrealiabe transport between them,
as is to be expected in an IoT use case. and we have someone sending iota transactions to both networks

(net A )  -  X  - ( net B )

because net A and B both have low connectivity to the rest of the world, they run their own little DAG that gets merged into the global DAG once in a while, to make the
transactions that happen in their networks actually valid.

Now in the input output model, when X sends a transaction to B, that transaction will be saved in the graph of B and will get
valideted by all transactions within B, sensors (inside B) can relatively  savely accept that transactions because a lot of transactions
inside B add a lot of POW to it, until the network is able to connect to global DAG.

In the balance model same thing happens BUT balance model would require that a node recieves every transaction from that account
to make sure the account is not double spending its coins.

double spending is a problem in both cases, but it seems to me low network connectivity would be less of a problem
in the input output model as nodes would not be required to get all transactions of X beause POW is added to that specifif output of X.
In balance model X could send a transaction into net B that might be invalid from the start, If that happens in input/output recieving a double spend
would not be a problem if net B can manage to add enugh POW so that once it gets merged into global DAG it is valid.

Corret me if i am wrong but balance model would complicate how the network comes to consensus A LOT.
So input/output model would be safer for small ( very small, so small they cant save full tangle ) IOTA sensors to accept transactions,
because they only have to check if that input is valid, not if all of the transsactions that this sender made is valid.

after careful consideration, I'll let the experts decide  
Sorry I'm a noob to this kind of response  
@child_harold, he just litle convinced and sometime you are true  

Edit: if you need time, i have no problem for this  

While I agree there is a finite amount of 'time' in a project before a beta should be released. I would prefer a functioning beta asap over waiting further, especially if we are talking GUI improvements over core functionality/viability. The brightest minds out there echo that minimum viable product wins over polished final when it comes to release cycles.

And where did you see that this issue is trivial as GUI. This dilemma is absolutely core functionality related and irreversible.
The few voting no for technical reasons are welcomed. But the few that vote no because they want it out now to.... you know.. sell it?
Are foolish beyond words.

 
Why are people in such a hurry ?
The more testing the better.
Why would you get angry that the software is released tomorrow or after tomorrow ?

Advice for everyone :
Go out, take some fresh air, walk and ask yourself if it's worth it to release a software that is not enough tested.

@charvesp, MickGhee, vlight: Some censorship has been done to keep the thread civilized.

Sounds great, have to think about your idea rlh!
For all users not on ryver

Cfb:

Just relayed information check this   

https://bt.irlbtc.com/view/1354220.0;topicseen

It's still good for me. I do focus switch while coding (this improves productivity) and these trolls help me because I don't need to put much effort into replies to them.