2 of 2 is standard multisig which is supported...
...on the blockchain but not the client currently. Meaning from the user's perspective it currently pretty much doesn't exist. Sorry but sometimes I get the frustrating (hopefully incorrect?) feeling that important features like multisig, offline transaction signing, and decoupling BTS voting keys from spending keys are being pushed aside for other things that are nice to have but IMHO lower priority (like escrow transactions, voting booth, Turing complete scripts, and frankly even the lightweight client is slightly less priority in my view than multisig/offline transaction signing/decoupling voting keys).
I don't see how this helps with cold storage concerns like some people in this thread are speculating that it does (at least not as long as offline transaction signing does not exist in the client).
The point of the cold storage is to not require the computer, which holds the private key that gives access to the funds, to be made accessible to the internet. Since the client does not currently have offline transaction signing, that means it needs to connect to the internet to broadcast its transaction.
So say you put your BTS wealth into an escrow transaction with three keys you ultimately control (sender key, receiver key, escrow key). The sender key is online because you had to broadcast the transaction to move your BTS into the escrow in the first place using your online client. The receiver and escrow key can initially be offline. But what if you want to get some part of the BTS back into your possession to spend it? Then you are forced to either bring the receiver or escrow key on to an online computer to broadcast the necessary transaction. At that point, if your computer(s) are compromised, an attacker can use the keys to release all of the funds to the sender and then send the sender's now released funds to the attacker. Also even if you succeed at only releasing a partial amount to the sender and the rest to the receiver, what happens when you want to get access to a little bit more? Now you need to bring the receiver key online to move the remaining funds back into a new escrow transaction!
This brings up an interesting question. Does this escrow implementation allow the sender/receiver/escrow accounts to each individually be multisig accounts? Ideally it should. If I am the sender or the receiver, I would ideally want to be able to send large funds to an escrow or receive funds from an escrow from/to my default 2-of-3 multisig address so that I am at no time exposed to theft if my hot client's private key is compromised. Allowing the escrow account to also be multisig adds security benefits there as well but also allows other interesting possibilities like requiring a group of people come to a consensus on how the funds should be divided between sender and receiver. This is not doable in a straightforward manner with a traditional multsig (although it is possible with threshold signatures like in CryptoNote), since you want just the sender and receiver (2 keys) to be able to divide funds between each other without requiring any outside intervention, but you also want to allow the escrow to be a M-of-N multisig (with M > 2) while still making it impossible for just 2 of the N escrow signatures (or 1 signature from either sender/receiver AND 1 of the N escrow signatures) from being enough to divide the funds between sender and receiver. Allowing multisig for the escrow account in this escrow transaction solves this problem. A crude approximation to this solution can be accomplished through traditional multisig by having a (N+M)-of-(3*N) multisig, where the sender holds N of the keys, the receiver holds another N of the keys, the remaining N keys are distributed among the N escrow parties, and of course M <= N is the number escrow parties that need to agree with a particular distribution between sender and receiver. Another (more general and efficient) solution would be to just implement threshold signatures so that each of the N keys in a multisig have a fractional weight associated with them and the transaction is only valid if the sum of only the weights associated to keys with valid signatures attached the transaction is greater than 1.