Privacy Issue: Unneccesarry merging of coins makes users more traceable (broken change management)
I noticed a bug that affects almost all wallets (as they seem to use wallet2.cpp). Essentially, Monero fund segregation / "coin control" is based on address (frozen, thaw, etc). From my research fund segregation is very important in Monero due to it's low anonymity set and the improbability of repeated merged outputs from unrelated parties. _Segregated funds should never merge together_

The issue is that **Monero sends all change to the same address**. This creates a merging nightmare because all those outputs will eventually be merged together. It might be 20 transactions from now, but when they are it creates a goldmine of probability heuristic info for chain analysis companies. It not only is bad from a privacy standpoint, but it is simply a bug from Monero's concept of coin control.

**The Problem**
Let's pretend that Addr0 is where all change is sent. User segregates Addr1 and Addr2 via the built-in coin-control (freeze, thaw, etc). As user spends Addr1 it's change is put in Addr0. Later, as the user spends Addr2, it's change is _also put in Addr0_. It creates a conundrum for the user. If they didn't also freeze Addr0 then outputs would have been merged long ago. However, even if they did, they will have a lot of balance in Addr0 which has _no option but to be merged together_ at which point their privacy is broken.

There are two possibilities here:

1. Either change handling is bugged 
2. Freeze / thaw (aka coin control) implementation is bugged and needs to be based on the output level and NOT address level (similar to feather wallet).

IMO, change handling is what is bugged because address-level coin control is far more intuitive and proper for the user. Output-level coin control introduces dusting attacks on the user unless they review all outputs in wallet before every spend. Address-level coin control does not have this issue.

The goal of output is that _privacy context_ should not change. Spent inputs belonging to one context should create change outputs that also belong to the same context. When privacy context is violated, user privacy is violated.
 
**The Solution**
I am not a programmer, so I cannot comment for sure, but I asked my programmer friend and he said that indeed the Monero code does mishandle change outputs. I do not understand the details, but I paste the corrected code he offered me and maybe it will be of help.

Basically, in two places in wallet2.cpp the following is called:

`change_dts.addr = get_subaddress({subaddr_account, 0});
change_dts.is_subaddress = subaddr_account != 0;
splitted_dsts.push_back(change_dts);`

**This code is problematic for two reasons:**

1. It forces all change into the same address thus giving them the same "privacy context"
2. It does not respect the passed transfer context already passed to the functions

**Here is the corrected code:**

`const cryptonote::subaddress_index input_subaddr = m_transfers[selected_transfers[0]].m_subaddr_index;
change_dts.addr = get_subaddress(input_subaddr);
change_dts.is_subaddress = input_subaddr.is_zero() == false;`

**Why is this a solution?**

It preserves the privacy context of the change. Change will never go into a different privacy context. This is an agnostic way because it uses the list of unspent outputs available to the transaction to derive the proper change address that will not violate the privacy context.

The result is that coin control (freeze / thaw) actually has value. If you keep two addresses frozen / thawed you can guarantee the outputs from the transactions they generate will never be merged later down the road. It also enables frozen / thawed to have use on the primary address. Currently, you cannot really freeze the primary address as soon your entire balance will end up in that address due to improper change handling and the result is you will have an unspendable wallet (until you thaw and merge everything to create a privacy nightmare).



