Is the intention that someone would open their non-private wallet, and choose an option that slowly siphons their funds into a different app?
Yes, that's the idea. And then send them back in a controlled manner.
Why would anyone want that feature?
Most mobile wallets have no coin control features, which are tricky to implement (lots of design/UI effort required). Some special purpose wallets have additional privacy concerns and also lack coin control - for example
protip.is may inadvertently disclose browsing habits, or bisq arbitration contracts are easily identifiable on the blockchain. The latter is actually an inspiration to this, since it has functionality to allow funding transactions from an external wallet, as well as withdrawing to one.
Conversely, fungibility focused wallets are highly specialized and limited in scope. As far as I'm aware, JoinMarket and Wasabi are the only maintained implementations of mixing wallets available today, and both are desktop apps, with no hardware wallet integration. It is unlikely that e.g. coinjoin functionality would be added the application specific wallets, especially as these features require a great deal of care and effort to do correctly (cf. SharedCoin)
The goal then is to allow people who are privacy conscious to utilize a specialized wallet automatically, to isolate the activity of wallets which don't provide a sufficient degree of control in order to achieve that manually, and reducing the possibility of operator error.
Could you describe what the UX would be like
From a payment standpoint the main difference is that change outputs would not be usable, so the spendable balance would drop. The best idea I have for handling that is to still display that balance but conveying that is locked. However, I think simply removing it from the balance is also acceptable. Funds would simply be added to the fungibility wallet similarly to how they are used manually today.
For setup, the fungibility wallet would need to add functionality to export these xpub variants, perhaps with a way of annotating what each account is for (but see concerns about BIP44 recoverability). Like standard xpubs, these would be easily conveyed by QR code.
The forwarding wallet would then offer an advanced configuration feature, that allows adding and enabling the alternate change address chain. If the fungibility wallet derives addresses differently, then the forwarding wallet should reject the configuration value (which is the main technical point of the writeup), to ensure funds are not misplaced.
or how a wallet developer might implement this?
For fungibility wallets, this requires keeping track of these address chains, and allowing them to be exported. This is similar to any sort of scanning functionality implemented in a BIP32 capable wallet, plus the UI to display them.
In the forwarding wallet, derivation of addresses is again already implemented in any BIP32 capable wallet (i.e. checking for the next free address), with the main change in the spending path being dependency injection required to change the address chain parameters (from what I know most BIP32 implementations are polymorphic with respect to derivations made from a public extended key vs. a private extended key). The main effort then is the setup functionality, which obviously will vary considerably between wallets, but I imagine it would still be a simpler and safer change than integrating comprehensive privacy features into the spend path directly.
If the user is privacy-conscious, why did they choose the non-private wallet to begin with? Why wouldn't they just move all their funds to the private wallet so they can continue to use just one app?
Platform limitations, or application specific use cases, see above. More broadly, the main rationale is that diverse, specialized wallets should be used in a complementary way, as that is more achievable than expecting all application specific wallets to have robust privacy features.
And if the user is not privacy-conscious, they would never choose to enable this option, so why would the wallet developer even bother to implement it?
I believe this is a low hanging fruit, easier to implement than coin control, far easier to implement than safe mixing functionality, so wallet developers (or contributes) would implement this to allow users more reliable access to privacy features implemented by other wallets.
From a product standpoint, I can't see how this would be useful, and therefore I'm not sure why it needs to be a BIP. If I'm missing something, please let me know!
The reason for documenting it in this way is because if deemed desirable functionality (which itself is something the BIP process can help determine), different implementations would need to agree on the details. I hope I've managed to convince you of the usefulness, though I'm still not sure about the practicality or desirability - as it stands right now I have received fairly comprehensive criticism from LaurentMT though, and I've been focusing on related idea to improve zerolink which I hope would to revisit this change forwarding idea and address his concerns when I have more clarity. The main weakness is the assumptions that fungibility wallets handle arbitrary amounts allowing those funds to be tumbled and recycled/consolidated, which realistically only applies to Join Market and even then only if used correctly.
Regards,
Yuval