I used FormEncode for a now-on-hold project and I really liked it for the most part. Being able to nest schemas was key for me. There were a few things that could have been easier though. Note that my usage was pretty strange though.
Error reporting wasn't flexible enough for me. IIRC I ended up subclassing schema and only changing a few lines (and it made me feel sick :). I wanted to catch validation errors at the top and decide what to do with them there.
I also wanted to add a bunch of state information to the validation errors. Errors needed to be persistent and I wanted a way of refering back to the validators that failed. (The whole point of the app was to run validations on existing data and to annotate errors, we didn't want to catch them up front.)
I think I ended up passing a state object around to the different validators to accomplish all this, but I was never happy with it.
Anyhow, if any of that interests you I'd be glad to talk about it more.
I'd like to talk about it, but it should probably wait until I figure out where this discussion and where further developments should occur. I don't want to have a discussion where we're not ready to make actionable decisions, because that's just a waste of people's time, but how to make that happen is what I think I need to figure out.
I also have used Formencode off and on for a couple things but haven't yet taken the big task to use a different form validation and scheme-building package for our bread-and-butter product, a dynamic survey-building tool.
We may eventually roll our own, but we're currently using FormKit to do it all and have had to build many work-arounds to fit our needs.
I, too, would like to talk to you further about the direction of formencode and how we could participate in its development and testing.
I will be at this year's Pycon so maybe a birds-of-a-feather meeting would be great, or even a sprint on the code would be good. What do you think?