DUP HASH160
ELSE
DUP HASH160
ENDIF
The output script will be plain ol p2sh:
To compare with your situation: Address "B" is the P2SH address for the above script. Address "C" / "D" are destinationOne / destinationTwo, and they have private keys c/d.
Q1 and Q2 can be different individuals, or just the same person with two private keys. HashDestinationOne and HashDestinationTwo would be the pubkey-hashes of the end public keys we want to authorize to redeem the coins.
We don't use addresses natively on the blockchain, we use hash locks and signatures. A destination is a specific requirement allowing a person to redeem the coins. Take the DUP .... CHECKSIG blocks - if that was the only script, it would have a 1something.... address. But in this case, we've stipulated Q1 needs to add their signature for this branch to be possible. Same for branch 2.
So a destination is just a set of conditions that can be met. In this case, OP requested different signatures to allow the funds to be redeemed at different destinations.
Q1 signature doesn't cause funds to move to destinationOne as there are additional requirements to be met, but once that party has the partially signed transaction, he can add his signature and move the coins. The owner of destinationTwo may even see the partially signed transaction for destinationOne, but he can't tamper with it to allow him access: Q2 has to sign.
Q1/Q2 will necessarily know where the party is moving their funds, and will have to sign that transaction. This isn't bad for privacy, because in another scheme, they could still observe spends from where-ever the coins end up. But it does sound like a way to provide federated access to bitcoin: sign by A and the funds belong to the user; sign by B, and we've got them.. *evil laugh*