This is “standard” behavior for T-addresses that Zcash inherited from Bitcoin. I’d actually prefer to change this behavior so that change returns to the sending address, and new addresses would only be generated when the user explicitly requests them. It sounds like you would prefer to use addresses in that matter. Is that correct? I filed zcash ticket #2675 to track this feature request.
Here’s a long story as to why Zcash and Bitcoin behave this way:
Early on many people thought it had fairly good privacy, because anyone could create an address at any time. However, the record of all transactions is public, including sender, recipient, amounts, and any stipulations put on those funds by Bitcoin Script. (In Zcash this is also true when transferring funds between T-addresses.)
In Bitcoin and Zcash, all funds live in “unspent outputs”. The transparent outputs in Zcash are the same as Bitcoin’s and they’re called “utxos”. If you have a 3 BTC utxo (you can think of a utxo like a cash bill) and wanted to spend 1 BTC out of address A, you have to split the utxo into a new 1 BTC utxo and a 2 BTC “change” UTXO, and assign the 1 BTC utxo to your intended recipient. But where do you assign the change? To me it seems most logical and convenient to assign it back to the sending address A. However, because the Bitcoin blockchain is fully transparent, this meant it would be easy to tell which output was for the recipient, and which was change. So for a desire for privacy, Bitcoin wallets tend to assign the change to a newly created address. It turns out this doesn’t provide much privacy at all, and analysis of the blockchain can deduce which outputs are change anyway, but early on people didn’t anticipate that very well.
This actually has several terrible consequences. First of all, some users would back up their wallets, then send some BTC which would generate new change addresses with new secret keys which weren’t backed up, then delete their wallet believing that their backup had saved everything. This destroyed their funds. Their assumption was quite reasonable, but the overly complicated behavior of the wallet violated their simpler, reasonable expectations (this is a common recipe for security failures in usability). [1]
Another consequence is that users can’t treat Bitcoin addresses or (current) Zcash T-addresses like “accounts” where they can separate their funds into different tranches and track them separately, for example “monthly expenditures”, “general savings”, “mortgage downpayment”, etc… So if you want to do that kind of accounting, Bitcoin addresses and (current) Zcash T-addresses don’t help you in that regard.
In Zcash we have Z-addresses which have very strong privacy, so the wallet sends change back to the sending address. This means a Z-address can be used for your own accounting purposes. You can have one for HODLing, one for your monthly bills, etc… You can list their transaction history separately, give them out separately to counterparties, etc… Also, if you back up a Z-address, you can rest assured that you will be able to recover all funds at that address at any time in the future without making a new backup. Very important.
Since Zcash has Z-addresses which provide strong privacy, I think it could be a good change to switch T-addresses to send change back to the sending address. Then a user could treat T-addresses and Z-addresses similarly in terms of backup and accounting. The drawback is marginally worse “privacy” for T-addresses, but those already don’t have privacy, just as Bitcoin addresses don’t. They are already vulnerable to blockchain analytics, so it’s seems like a waste to sacrifice backup and “sensible accounting” for the illusion of privacy.
[1] It many Bitcoin wallets with BIP32 “hierarchical deterministic wallets” this backup problem is solved because all new addresses get generated from the same secret seed which is backed up. This “fixes” the backup problem by adding complexity (BIP32 generation) to overcome overly complicated behavior (random change addresses) which provides no real privacy, and still makes the user’s life more complicated (no accounting support). Zcashd doesn’t have this behavior yet, but we should add it because the “backup mistake” is a disasterous experience for users.