usually you apply the discount at the shopping cart stage, the price is then recalculated at checkout, could be done that way but it's a little cumbersome.
One way to implement a token-based discount is that whoever owns/holds a token gets the discount. Another way (that I had in mind) requires you to transfer it back to the store. In this case it is lot more convenient to transfer both BTC and Counterparty token in the same transaction.
theoritally it's fine to replace the antidust amount sent to the recipipient with any amount larger. However, it's not implemented in the current counterpartyd yet. Maybe later we can customize the amount of BTC we sent in xcp transactions, but I am not sure whether this is really useful.
It actually is implemented, both in the CLI and the API, at a per-transaction level:
--regular-dust-size REGULAR_DUST_SIZE
value for dust Pay‐to‐Pubkey‐Hash outputs, in BTC
--multisig-dust-size MULTISIG_DUST_SIZE
for dust OP_CHECKMULTISIG outputs, in BTC
It's useful if you're making a *lot* of (similar) transactions, and want to lower your costs as much as possible. The default fee and dust values are very generous, because they have to work well in all circumstances.
Oops, sorry about my mistake. I see now, these parameters are provided for users to lower the fees in the first place, but certainly can be used to increase the amount so that BTC transfer and counterparty transfer can live together in one transaction. Great.