ZmnSCPxj explains that even with SAS, a third transaction is still necessary, especially when dealing with non-SAS aware payees that only provide onchain addresses. The 2-of-2 output from the swap cannot be handed over to the payee as it will not be their onchain address, and they will still want unambiguous ownership of the entire UTXO. Thus, a second transaction is needed. Additionally, if Alice wants to use only an HD key and not store the remote-generated privkey, a second transaction is also necessary. Furthermore, if Bob is operating as a maker, he cannot directly use the 2-of-2 output from the swap and must make a new 2-of-2 output for the next taker that requests his services. Despite this, SAS can still be useful in avoiding a third transaction to move from a 1-of-1 to the next address that makers and takers will be moving anyway, and in not having to add communication provisions for special things like adding maker inputs or specifying all destination addresses for the second stage and so on. In terms of multi-maker SAS, ZmnSCPxj notes that S6 requires timelocks for each output to function, making it unlikely that it can be made to work with SAS. However, the mild advantage of S6 is that all funding transactions paying to 2-of-2s can appear on the same block, whereas chaining swaps will have a particular order of when the transactions appear onchain, which may be used to derive the order of swaps.