There is a missing piece in your picture, the trade offers selling BTC/Bitstamp for XRP. The values you give won't work currently since the best offers in the order book are in the range of 8300 XRP/BTC or 830 XRP for the 0.1 BTC you mention.
If the values you give were adjusted or if we assumed an alternate reality where 10 XRP could buy 0.1 BTC/Bitstamp then the following should (see note at bottom*) be what a user would see if they were to go to the client's "send" page (sorry no picture):
Recipient: C
Recipient will receive: 0.1 BTC
You can send:
10.000 XRP <Send XRP button>
1.00 USD <Send USD button>
Since User B has no BTC there is no BTC option given. If the user selects "Send XRP" then a payment path such as the following would be used:
User B 10.000 XRP
--> trade offer for 10XRP to 0.1 BTC/Bitstamp
--> Bitstamp
--> User C
User B's balance goes down by 10.000 XRP. The unknown person making the trade offer has their balance go up by 10 XRP and down by 0.1 BTC/Bitstamp. Bitstamp's balances are adjusted so that 0.1 BTC less is "owed" to the trader and 0.1 BTC more is "owed" to User C. User C's balance goes up by 0.1 BTC/Bitstamp.
If instead User A selects "Send USD" then a payment path such as the following would be used:
User B 1.00 USD/A
--> User A's offer giving 10.000 XRP for 1.00 USD
[then as above]
--> trade offer for 10XRP to 0.1 BTC/Bitstamp
--> Bitstamp
--> User C
User B's balance goes down by 1.00 USD/A. User A's balance goes up by 1.00 USD/A (they owe one less USD to User B) and User A's balance goes down by 10.000 XRP. Then it's as in the previous case: The unknown person making the trade offer has their balance go up by 10 XRP and down by 0.1 BTC/Bitstamp. Bitstamp's balances are adjusted so that 0.1 BTC less is "owed" to the trader and 0.1 BTC more is "owed" to User C. User C's balance goes up by 0.1 BTC/Bitstamp.
In both cases User C considers the payment from User A complete by ending up with a larger balance with Bitstamp. All of these balance changes happen atomically within a single transaction, either all the balances change or none of them do (e.g. if the transaction fails because a required trade offer is consumed or canceled before this transaction can be processed). User B never ends up holding something they didn't want to hold (e.g. BTC/Bitstamp).
- Note that path finding in Ripple is not exhaustive, not all valid paths are found. As David Schwartz says above, pathfinding is an area they are constantly improving. If the option to pay with USD as shown above is not presented currently then it's likely it will be as the pathfinding is improved.
Also note that I omitted Bitstamp's 0.2% transfer fee for simplicity. The above values would work for sending 1/1.002 =~ 0.998 BTC at a cost of 0.1 BTC/Bitstamp==10 XRP – dchapes – 2013-05-17T20:32:09.440
Oh and I also neglected the 0.000010 XRP transaction fee that will be subtracted from User B's balance when the transaction is confirmed and submitted (even if the transaction fails as described above; in that case the only balance changed will be the XRP balance of User A and only by the tx fee amount). – dchapes – 2013-05-17T20:35:29.183