Most of what I saw solves a problem in the same space as a custom tag set that I have been using for a few years (and hoping to put into beta soon). So, I am likely somewhat biased about what I saw.
That being said, I was really impressed with what I saw. It was interesting to see where John and I took similar approaches and where our solutions differed.
COOP seems to rely on a CFC in the same folder as the calling file and with the same name (except the .cfc) extension. John called this a "coprocessor". It looked a lot like a page controller to me. I have mixed feelings about this. On one hand, I was unsure of how I felt about introducing a requirement for an external file for each page. On the other hand, I generally like the use of a page controller.
He has several different kinds of form fields available. One thing that I noticed is that he has a "RadioButtonList" and "CheckboxList" where I named mine "radio" and "checkbox" for similar functionality. His name here is a much better description of the functionality and I wish I had thought of it.
His approach did seam to write table tags instead of providing an option for a more semantic style as well. He also used a separate tag for a label than for a form field. In one way, I didn't like this difference in approach as it made the code longer and required tables. The advantage of this option, however, is that it makes it easy to have multiple fields on one row with one label - something difficult with my approach.
This made for some nice-looking forms that seemed very "tight" in their presentation (which I liked).
He also allows pass-through attributes in his tag. This means that any attribute not directly used by the tag, will be written as an attribute in the HTML element. For example, you could add a "style" attribute to any tag. This is something we have in common, though I think I may have a list of pass-through attributes, which isn't as flexible an approach as John seems to have in COOP.
COOP allows you to specify a validation method from the coprocessor as well as using the coprocessor for other settings and data. This does provide a bit of an external dependency, but makes for a very nice separation of display and logic. John explained that his goal was that a non-programmer could handle the display code for the form.
The form is self-posting by default, but you can specify an action attribute if you prefer. This does circumvent the built-in validation, but John said that given the separation between the logic and display it should be easy to allow for validation even if the form isn't self-posting.
He is working on adding AJAX support and has complete documentation almost complete.
Overall, this looks like a very good offering. Indeed, Sean Corfield said "COOP looks very nice and cleanly architected".
If you are looking for a good form custom tag set, this is definitely worth a look. In the meantime, check out his recording.