Arnon Rotem-Gal-Oz has a nice blog entry on RETRO (the whole rest-discuss thread is also neatly summarized by Mark Little for InfoQ):

On the good side, I have to say, it is one of the best RESTful models I’ve seen thus far. The authors took special care to satisfy the different REST constraints, unlike many “RESTful” services (e.g. twitter that returns identifier and not URIs).

I agree, this is a very well-though out solution.

On the downside is I think a distributed transaction model is bad for REST or in other words I don’t see a reason for going through this effort and jumping through all these hoops.

I tend to agree — I'm not at all sure we need standardization here.

Since using hypermedia as the engine of state change means that the hypermedia actually describes the protocol, we clutter the business representations (the representations of real business entities like customer, order etc.) with transactional nitty-gritty.

Now this is something I don't agree with — if it's done, this is the way to do it; not hiding the details somewhere else.

It seems to me that RETRO is a good mental exercise to show transactions can be RESTful. I think, however that it is an overkill for RESTful implementations.

I agree again. In my opinion, transactions in REST should be a pattern, not an implementation (see this entry for some motivation for this).