I understand the concerns, and would definitely like to find a good way to do it with unhardened paths.
I suppose random works, but as you said it’s another nonsensical thing for the user to check. Not sure if we are willing to accept this compromise.
It could be to keep a “standard” path for export, and add a few unhardened depths of randomness on top.
m/48'/0'/0'/2'/[RANDOM]/[RANDOM]/[RANDOM]/[...]
or equivalent. The export from the signing device would still be the xpub at m/48’/0’/0’/2’, but it would need to be able to accept a descriptor with a few extra unhardened depths for signing and address verification.
I’m not sure it is supported by hardware signers right now. I’m also not sure how many depth we would need to offer a reasonable privacy protection.
I wouldn’t go for unix or date/time completely unhardened, as I want to be able to switch software (and import my descriptor) without breaking the privacy of my other wallets. Unix or Date/time reduces the range too much and would need randomness on top.
Edit: I clarified that the xpub would be still shared on the “standard” path, but then random unhardened derivations could be added on top, on the software/service side, without access to the hardware signer