CommitBlockChain
This way of resolving commit message disputes is probably overly complex for Ripple. We don't need one canonical record of commit messages, we just need a way for any two nodes to agree on a third party to act as arbiter for any disputes.
Idea
Transactions would be processed following the real-time model. The main issue with that model is when there is a real or feigned connectivity problem between two intermediaries, and the commit message doesn't make it back to the payer before the transaction expires. It is then up to the two intermediaries to sort out who was responsible for the outage, and who will get stuck with the loss. Agreeing ahead of time on a trusted third party to time-stamp and attempt to forward these frustrated commit messages, and then referee any further dispute based on its observations of the two intermediaries' hosts' behaviour is one solution to the issue. But a better solution might be for the payment recipient or any other intermediary to broadcast the commit message (which doesn't identify any of the parties, and only the recipient can create) for inclusion in a global block chain of such messages, where every intermediary can see and agree that it was exists and was generated in a certain time frame, and therefore must live up to its promise.
The goal here isn't to replace the real-time processing of the commit message back down the transaction route, it is just to moot any attempted shenanigans as well as to resolve any disputes about whether a particular transaction promise between two intermediaries must be fulfilled or not. To that end, promises should be set to expire, not at a certain time, but after a certain number of blocks have passed. So any intermediary thinking about trying to gain from deceitfully refusing a commit message would have odds of success equal to the odds of the commit message being left out of the next N blocks -- pretty tiny odds, I think. Therefore the commit message should be passed along in a timely manner back to the payer, who can then present it to the recipient as proof of payment and collect her goods. And if an intermediary happened to go offline honestly for the duration of the transaction, the payer would receive the commit message broadcast over the whole network regardless.
An attack on this would be for the payer to control all the peers connected to the recipient and every intermediary, so no one can broadcast the commit message and it never gets into the block chain, but yet the payer gets it and uses it as proof of purchase to collect good from the recipient. Bitcoin already has some strategies to try to avoid anyone being able to monopolize anyone's connections, and monopolizing multiple peers' broadcast connections seems like it would be very difficult, especially if peers broadcast to all their connections' servers.
Block Chain Scope
A block chain should be not only for all nodes connected in the same isolated credit network, it should be for all nodes whose servers are connected in the same data network. There may be multiple disconnected credit networks using the same block chain. A single block chain per data network is stronger and more resistant to attack.
Fees
Anyone who wants a commit message included in the block chain can attach a processing fee to encourage its inclusion. It is not always useful to pay these fees with regular Ripple transactions, since a single block chain may span multiple disconnected credit networks, and IOUs between them may have no meaning.
One solution is to generate Ripplecoins similar to Bitcoins with each block, and allow those to be attached to commit messages as fees. Then, if the generating servers overall feel they are not receiving enough for their work, they can start dropping commit messages that don't include enough fees. This will motivate other servers that care about their messages being included to start including more Ripplecoins, driving up demand, and increasing their exchange value, increasing the reward that generating servers get for their work. This will motivate more servers to work on computing blocks, and ensure the block chain is as strong as possible.
Merging Networks
It's possible that two distinct data networks of Ripple servers exist, each with their own block chain. They might eventually merge by a connection between nodes from both. In this case, the more difficult block chain should take over, and all servers should work on extending that one. Those servers that care can still store the old one as proof of commit messages therein, if need be. Until the next difficulty target update, blocks will get computed faster.
Ripplecoins complicate the merging somewhat. One possibility is that the Ripplecoins from each network get assigned a new value equal to the total work that went into the chain they were generated from, relative to the other chain.