This is still not private, since the hash of x appears in both chains. They would use different pubkeys on the different chains, so the pink key on chain W would differ from the pink key on Y, but the x value must be the same on both chains. MAST allows the first transaction to be rewritten so that only one of the three redeem conditions needs to be revealed. In the cooperative case, neither x nor hash(x) needs to be revealed publicly on Blockchain Y. Both Alice and Bob will know the all the redeem conditions to protect themselves, but won’t reveal unless needed. Here is how the first transaction would be constructed:

Merkle tree of possible spending options

MAST allows us to instead represent this script as a tree. The combining of colors represents hashing. The brown hash at the top is what locks up the coins. The coins can be spent if a proof that colors (hashes) can be combined to a leaf color which matches a spend condition. Also, the tree can be unbalanced, where a shorter proof (smaller cheaper transaction) is used in the common cooperative case. In the below example, they show that blue and pink combine to make a violet multisig. They then show violet and orange make brown. Thus after proving pink and blue are allowed, 2 of 2 signatures from Alice and Bob can move the coins. This looks like any ordinary MAST based 2 of 2 multisig on the blockchain. The public sees none of the fancy protection parts, just the orange hash. The important part is neither x nor hash(x) appears on Blockchain Y, increasing privacy. The public can’t even see that it’s a swap transaction.