Yep, I had read your twitter thread reply / rebuttal and it was excellent - a level-headed, realistic assessment of the severity of the issue! (Yes, it exists, but isn’t necessarily a very common problem.)
But for some, the likelihood of the problem needs to be shifted closer to zero, or completely be zero, hence this (hopefully only pre-Halo) tip of basic churning.
As you say:
Indeed, consequences of Zcash tracing should be understood in context. Maybe one’s shielded ZEC (or whatever they attach it to off-chain) is anonymous enough to an attacker that they can’t do anything with the linkage anyway. (But it’s also about minimising ZCash as a possible weak point in their privacy/anonymity - or, optimistically, making it your strongest point.)
Jeez. Each time I learn something new about Monero, the worse it looks. I already had given up hope in Monero (but hope they improve it of course), except to use it as another layer sometimes (e.g. a final payment layer post-ZEC if some product seller doesn’t accept ZEC, or for other forms of layering for reasons like hiding the fact from a merchant that I have (‘further’) ‘anonymised’ some XMR with ZEC technology (to not reveal to them exactly how anonymised the money is), or for other reasons).
To me, now, XMR seems best to use while covering your eyes and hoping for the best (i.e. faith, religion).* Funny how people think of it as the ‘Tor’ of cryptocurrency. Zcash is BETTER than Tor, for cryptocurrency. (It provides superior anonymity and privacy protection for your money than Tor does for your IP address. It’s quantum private. Tor isn’t.) This astounding fact is still sinking in, it’s amazing, and it seems it’s been this good basically from the beginning. 
Corrected in subsequent post below.
(I would have just churned at least once back in the Sprout era, though the smaller shielded crowd to hide in would have made it less convenient - more time between churning required, and more stressful - to be at the same level of OPSEC compared to what’s reasonably doable currently. As for the Orchard+ future with shielding / shielded much more defaulted, it looks BRIGHT!)
[*] XMR developers are probably just as honest as Zcash team - I noticed the ‘Breaking Monero’ series - I’m really dissing the Monero user crowd, which seems in complete denial very often.
@zooko thanks for the tip about monero churning possibly making monero OPSEC worse. Will look into that. I know a big principle is that extra complexity in security can make it worse - simplicity can be safer and secure (less ‘attack surface’ and points of failure). Sometimes more complexity is better (it makes it harder for a certain attacker to hack their way through the extra sh!t you put in front of them) - but it depends on the mechanism at play. When more complexity does help, I call it “defence surface” (a larger shield to fend off the incoming arrows - more points of failure for the attacker) - I see others use that term. Can also be complex. If you have multiple simultaneous enemies, it may be better to be (or to look) simpler to one enemy, but more complex (e.g. more parts to your chain) to the other enemy, so you must compromise in the middle, choose which enemy to defend against more strongly, or compartmentalise, which is a lot of work and inconvenience, but very powerful. Complicated, but always fun.
So on to the main course: are decisions still being made (for reference wallets) on what the default number of notes per transaction will be (and/or auto merging/splitting behaviour)?
IIUC, no higher amount of default notes (inputs/outputs/actions) set per transaction could be reliably safe against dusting, since attacker only needs to send a TX to a victim with more than the default number of inputs (so say it were set to 10, they’ll just dust you 11 - then, if you want to send the full wallet’s amount in a subsequent outgoing TX and didn’t have any other notes prior to that, the TX will show the ‘1 more note than usual’ count, and stand out - UNLESS wallets auto merged >10 unspent notes always to a maximum of 10, but that seems unnecessarily expensive, e.g. outgoing TX would have to always split or merge into preisely 10 notes).
To reconcile insta-tipping with de-dusting, could the ideal default (to not have to churn, even for high security users) be:
- Auto note merging into exactly 1 note at all times (attackers thus can’t possibly succeed - even if they send muli-note ‘dust’ to someone e.g. via a custom, non-official, third-party client taking advantage of the fact that multi-note transferring is still flexibly allowed by the protocol, users of official/reference wallets are auto-protected from dust due to auto-merging, thus churning is not required.) [Then official wallet might not even need to decide on how many notes to set as default in outgoing TXs - with default settings it’s necessarily 1 note always, as that’s all there is to choose from.]
- Rely on Orchard transactions being fast enough so that insta-tipping will only be a few seconds wait?
So: indeed, do what @daira has suggested in 2020? Note merging as a defence against input arity correlation attacks · Issue #4332 · zcash/zcash · GitHub
Whatever happens (Halo sounds better every time I learn more about it, best of luck in this final prep period next few months), I’ll always at least check on a ZEC blockchain explorer what the current most common input/output/action ‘fingerprint’ is (i.e. how many of such things show on TXs), and just do what I need to do, if need be, to match that.
Of course, unnecessary OPSEC isn’t desired even by me, so if I don’t have to churn in Halo+Orchard after verifying how it finally behaves, then that’s fantastic, I can put my hoe down, grab a coffee, then tip someone only ~4 seconds later.
PS: why can’t protocol just change to not allow dusting? (Typical use looks like only one output note goes to recipient,s so why allow someone to send dusty TXs to people? There must be legit use I don’t know about - efficiency or something fundamental. I’m still a cryptocurrency newbie, apologies.)