Other than #3 these are all covered in MRL-0004. One solution is to send multiple transactions to the recipient, adding up to the desired amount, ideally with some time delay.
Linkability issues and how to (maybe) solve them
So I was thinking today and came to the conclusion that there are (maybe) some linkability issues if during mixin we just pull random TXO's from the chain in some cases.
Say I received 1234 XMR (1000 XMR, 200 XMR, 30 XMR and 4 XMR) in a brand new wallet. I want to send 230 XMR with mixin 5. So I will use my 200 XMR and 30 XMR TXO. I select 5*2 random TXO's for the 200 XMR and 30 XMR. (that's how it currently works I think)
=> the outputs 200 and 30 are linked together if they came from the same ring signature transaction.
How to (maybe) solve this problem, just some random thoughts on TXO selection:
try to use "unlinked" TXO's if possible (so no TXO's who appeared together in a ring signature) by selecting TXO's in your wallet who are not originating from the same ring signature transaction.
try to use a bigger TXO (in this example 1000 XMR) if (1) isn't possible. You will use change now, so this has the benefit of creating new (in this case a 700 and 70 XMR) TXO's in your wallet. It does expose a bit of info to the receiver of the 230 XMR, who can calculate your change (at least if he assumes you didn't send money to different people in one transaction). This is probably a very good idea when RingCT is implemented so your change amount won't be exposed.
if (2) also isn't possible, try to use linked inputs from other transactions. I'm guessing this will take a long time to generate such a transaction because you need to find a single Ring Sig where both a 200 and 30 XMR were used. Maybe have this as an option or something. The problem I still see with option (3) is that when we discourage the use of linked TXO's, these will become more rare over time. So in 10 years time, when you choose option (3) it will be more probable that the most recent TXO's will be spent TXO's. This problem can be solved however by giving people the option to include such outputs even when it's not needed. The generating of transactions will take more time, but by doing so, they are obfuscating the blockchain even more.
Maybe an alternative for (3) is the just display Warning: you are about to use linked outputs. Would you like to premix? Y/N If the user agrees, the needed TXO's will be send back the user in separate transactions.
thoughts?
I think that's the easiest solution. This technique is called merge avoidance and has been proposed to Bitcoin wallets as well. The only tricky part is whether to delay the sending of the multiple transactions, and of how much. Too much delay harms usability (the receiver won't see the money in immediately), too little allows for easy timing associations.
Is this solution being implemented in the new release that will ban 0 mixin?
Fluffypony and othe made me aware of the fact that in most cases this won't be an issue anymore once RingCT is implemented because you can use an arbitrary amount as input for your transaction. Although it's still possible that you will need to combine inputs originating from the same Ring Signature Transaction in some edge cases. I don't know if option 3 or 4 is the solution.
In theory, the idea is to have only one output going to each recipient with RingCT (so the typical transaction would be one payment, one change). Therefore, there will be no possibility to spend multiple outputs from the same TX.
There may be some practical considerations that make that infeasible to do all the time, but we should get close.
One last point. Even if you do see multiple outputs from the same tx it only shifts the probabilities, but doesn't prove anything. There is still no likability, strictly speaking. Not ideal though.