User A buys a USDCoin at current market rate, say 1/14 BTC. Current market rate moves to $15/BTC and user trades in his USDCoin for 1/15 BTC. Fantastic. User B decides $/BTC will move down, so he buys a USDCoin for 1/15 BTC. He is right and wants to cash in his USDCoin. Whoops! Either the value of the bitcoins in escrow has to somehow fluctuate with the asset (impossible), or you have to pray it doesn't move against the hedge.
You are quite right that trades cannot be made between users and escrow. The protocol would have to match users to each other directly. That is what I mean by the exchange rate fluctuating separately from real life.
Here is the example I would use:
User converts his bitcoins to USDcoinsBehind the scenes, his bitcoin client puts his bitcoins into the escrow fund. In return he gets USDCoins. The protocol gets those USDCoins by either 1) Buying them from another user who is selling them OR 2) Creating them out of thin air, and also creating balancing AntiUSDCoins, which it sells to another user. One of those options will be a net win for the escrow fund, and that will be the option chosen.
User later converts his USDCoins back to bitcoinsBehind the scenes, his bitcoin client either 1) Sells his USDCoins to another user, or 2) Buys AntiUSDCoins from another user and destroys both the USDCoins and the AntiUSDCoins. One of those options will be a net win for the escrow fund, and that will be the option chosen. The resulting bitcoins are then credited to the user.
In order to converge prices on reality, the protocol could charge a slightly higher fee the further you trade from the current external exchange rate.
Obviously the example above is more of a "market order" type of trade. Limit orders would also be needed to provide liquidity.