While calling getbalance or getbalance '*' returns the current available balance, getbalance accountName returns the amount of all received coins to the given account. This is inconsistent and in my opinion is a bug. If it is intended behavior, than it is confusing and the command should be changed to something like gettotalreceived accountName.
I compiled version from github few days ago on Kubuntu. getinfo returns version 69900
An update, which I think is related.
gettransactions accountName returns only 'receive' transactions. To get 'send' transactions one must use the default ' ' (no name) account. This also includes 'generate' transactions that actually go to a specific account.
By default, all sent transactions take their credit from the "" account. If you want them to take their balance from another account, use the sendfrom RPC command.
Note that accounts have almost nothing to do with addresses or the actual coin selection. They are just virtual balances kept, for example if you have several users.
OK, I can agree with logic that gettransactions accName return only transactions explicitly bound, by client, to that account, as accounts are virtual. But still getbalance accName does not return actual balance. Or in better wording: The default setting of the client (sends by default from "" acc) will make balances per account misleading at least.
eg. if I had received 250BTC on 2 accounts, spent 450, and now the getbalance returns 50, getbalance acc1 returns 250 as well as getbalance acc2 - As a normal user I would think that something is broken...
If calculating balance from addresses bound to the account is not planned, than I think getbalance should only return total balance and the per account option should be disabled or moved to another command as they don't provide the same functionality.
Then we need better documentation I guess. Get the balance of ""
I agree that a better separation / isolation of the "account" system would be nice. It is confusing and error-prone that the command set used for the entire wallet, and that for the individual accounts overlaps.
I also think that the account system can be deprecated completely when we have full multi-wallet support (and expose it on JSON-RPC, for example by distinguishing the wallet used based on HTTP username). Otherwise it will become very complex, with two levels of nesting.
Then again; many clients rely on the current behavior. Changing it will require multiple deprecation steps over a long time. Maybe something for the "1.0.0" roadmap.