A colleague just gave me the advice to use a tabbed object at each branching point, and set the script trigger to go to the correct tab depending on what they enter (by using Go To Object). This will cut down on my real estate and is cleaner than making several new layouts, so it's currently my best option. And since you can set the tab width to 0 pt, you don't need to worry about someone clicking on an invisible tab or seeing it there. I am considering this answered, though any better solutions out there are welcome!
research hierarchical portals. The "child list" changes as each "parent" is toggled. Rather than a Manual toggle you could base it on an answer not empty.
Don't know if this is exactly what you're looking for, but here goes...
I had a similar situation where there were several forms with different sets of questions. I didn't want to set up specific layouts for each form, so instead I set up a table for Questions and a table for Answers.
Forms are pre-defined in the Questions table, which allows grouping questions into sections with section titles, and allows for specifying what type of answer is expected for all questions in the section -- for example, multiple choice (references another table of multiple choice possibilities), text, or check box. There is version control, so if a form changes, it goes from 1001A to 1001B, etc.
When a person goes to fill out a form, a new record is created in the Answers table. Fields contain info about the user and form version, such as 1001B. There's a relationship back to the Questions table to pull information about the sections, questions, etc. Questions are presented in sections. There's one layout for each type of expected answer (text, multiple choice, check box). Fields on these layouts are globals. "Forward" and "Back" buttons allow them to move between sections. As they move to a section, any answers stored in the Answers table are put in the globals. When they leave a section, their latest answers are copied from the globals to the Answers table. (I know I'm bucking a trend here, but I use repeating fields to store both the questions and answers for each section. They can have up to 20 sections in a form, and 25 question/answer pairs within each section. So each table has 20 repeating fields, each with 25 repetitions.)
This was originally created for use in FileMaker, but most forms are now filled out on the web using CWP. That transition actually wasn't too bad. On the web, there obviously aren't layouts for each type of expected answer, but instead it builds the <INPUT> statements for each question/answer based on the info in Questions. Form definition and review/reporting are still done in FileMaker.
I think you could build the branching you need into the Questions table, or possibly a set up a related Subquestions table where the relationship is dependen t on their answers to specific questions.