I understand that this protocol doesn’t speed up the need for confirmation. If Alice has already waited for confirmation to the swap address, Bob can trust 0-conf. If Bob opens a channel from payjoin-in-potentiam external funds, Bob wants to wait for confirmation.
Either way a single confirmation, either to the swap or in a payjoin, is still required from the source of funds.
SIP is clearly a simpler protocol that should be deployed correctly before being optimized for batched fee saving.
Correctness is absolutely more important than an optimization. However I don’t think that’s the trade-off PIP makes.
I see why SIP is awesome and want to build more on the idea. PIP is just an optimization to save fees with an SIP failsafe. It also provides the LSP with an opportunity for those outside funds to pay for an LSP consolidation or transaction cut-through and preserve privacy via a transaction topology including indistinguishable sender and receiver input.
I know when I’m expecting incoming funds I often keep refreshing the page waiting for it to land in my wallet. In that case, both Alice and Bob can save blockspace fees and create less congestion in mempool. A comparison of payjoin-in-potentiam to the correct swap-in-potentiam common case does not make much sense to me because PIP subsumes the common case SIP entirely. Do you foresee some way that it would break that common case assuming a correct implementation? I see that ensuring correct implementation is also an important and valid concern on your mind.