Oh, sure, just make it sound simple. (: This seems like a fine solution. I still slightly prefer mine but for no really compelling reasons (they mostly boil down to personal taste). I'll summarize them, just FYI (where "Y" stand for "y'all's" in this case).

I think my method will also be useful for giving feed back to non-editors replying to nodes.

I find picking the right time-out (5 minutes) to often be a continuing source of change requests. There are inevitably going to be cases where it seems too long or too short. My scheme mostly lets the humans evaluate the situation to determine a good time-out value (and I'd prefer that hitting "Preview" updates the time that is displayed to the next editor(s)). Adam has already noted that he disagrees with me on that. I have a time-out value, but it isn't a critical one and can be made very long with little problem (you just get notified that jcwren might still be editting a node even though it has been an entire hour since he started). But, like I said, personal taste.

I find optimistic locking often much easier to implement correctly (when you get down to the little details) because the locking and unlocking happen very close together and so can be done in the same subroutine, for example.

        - tye (but my friends call me "Tye")