Users have to create, share, distribute, and manage partially signed transactions. This is not viable for almost all users. Only the most paranoid and patient of users. The infrastructure required to "get this right" is significant.
As a general policy I think there should be no situation where a user cannot sign and submit a valid transaction to the blockchain. Multisig is a generic tool employed by Bitcoin to solve any arbitrary voting policy on spending funds. Being generic means it is harder to use.
Your escrow-specific transaction is a nice bonus to the traditional multisig, but I am more interested in the second use case: multi-factor authentication.
Following the policy that a user should be able to sign and submit a valid transaction to the blockchain without having to first coordinate partially signed transactions out-of-band, why not allow submitting partially signed transactions to the blockchain with additional signatures added later? So, there could be a balance on the blockchain sitting in an output of tx1 which is spendable by an M-of-N multisig transaction. I can then submit tx2 intending to spend the output of tx1 and sign the transaction using one of the N keys. The transaction could also pay in advance for the other (M-1) mini-transactions that need to be added to make the transaction whole and active; this way the next (M-1) unique mini-transactions providing the other necessary signatures can be added to the blockchain at no cost to the signers. The other (N-1) entities can be alerted in their clients (either through the TITAN check mechanism that already exists and/or the mail server notification system for lightweight clients that is planned) that there is a partially-signed transaction on the blockchain awaiting further signatures that they can provide. Then, if (M-1) of those (N-1) agree to sign that partially-signed transaction which would add their signatures to the blockchain as they each sign, the transaction will become whole and activated (meaning the funds would have been officially moved from the output of tx1 to the output of tx2). Prior to activation, those transactions are just data sitting on the blockchain, the output of tx1 is still valid, and it is possible for another transaction to spend the output before tx2.
Edit: I just thought of another improvement. In TITAN the encrypted memo field has two pieces of information: the sender information along with the SHORT_SIGNATURE to prove it, and the memo text. I suggest splitting these two pieces of information so that they are encrypted with separate keys. The sender information and SHORT_SIGNATURE would be encrypted by SECRET1, and the memo text + SECRET1 would be encrypted by SECRET, where OneTimePrivateKey * RECIPIENT_EXT_PUBLIC_KEY => SECRET. OneTimePrivateKey * SECONDARY_EXT_PUBLIC_KEY => SECRET1, where SECONDARY_EXT_PUBLIC_KEY is one of the public keys in the multisig transaction that is spending the funds. This way the holder of RECIPIENT_EXT_PRIVATE_KEY (the main recipient of the multisig transaction) can decrypt both the sender information and the memo text as usual, while the holder of SECONDARY_EXT_PRIVATE_KEY (likely the second-factor authentication service) can only see the sender information but not the memo text. The holder of SECONDARY_EXT_PRIVATE_KEY can check that one of the RECEIVE_PUBLIC_KEYs in the multisig output of tx1 belong to it, that tx2 has legitimately initiated the multisig transaction spending the tx1 output, and by decrypting the sender information in the memo field of tx2 it can determine which of its customers initiated the transaction. This allows it to know who to contact for further verification (say SMS verification or a telephone conversation) before adding their signature through a mini-transaction to the multisig transaction.