As the author of Workflow, the thought of basing survey on workflow scares me. Maybe I'm just a sop, but I'd recommend against it.
First, Workflow's a long way away from where I want it to be. The notion of describing some process using Petri Nets (or some other language which translates into Petri Nets), and having stuff happen at each step along the way, is beautiful (I should think so, no?), but right now, due to a number of factors, including the fact that integration between database tables, PL/SQL, web server, and page scripts, is a lot less flexible than could be desired, things aren's as neat as I'd wish they were.
Second, even if it was where I wanted it to be, it wouldn't have anything to do with branching in a survey. I'm all for focusing on differences in use cases, and going for the most optimal user experience for each individual use case. The use case of processing an insurance company claim (which is the original model behind workflow) is very different from a branching survey, and I'm pretty certain that even though I'd created the ideal user experience for the insurance-claim type workflow, it'd have sucked for the survey use case.
That doesn't by any means preclude writing some common infrastructure here. All I'm saying is obeyi Pind's Rule of Five, and focus on creating the most ideal user experience for your particular class of use cases. And if you later find out there's code worth sharing, do some refactoring.
/Lars
