We can't predict the maximum number of members, so the entry page has two submit buttons: one indicating we have another member to fill in, and another for indicating we're done and should save all the information to the database.
...
I haven't studied C::P enough to know if it will handle this sort of thing better, but I suspect it will.
Yes. The basic theory is that there's an app-wide "dispatch" that figures out what state you are in. Then a specific "respond" gets called, which can notice which button was pressed, and return whether to stay on the same page (return $self), or go to a new page (return $self->nametopage("next")). Whichever page gets selected for rendering then does the render thing.
To me, this makes a lot of sense in practice. When you're editing a given page, you have one editor window open on the .tt file, which describes how it looks and what fields it returns, and another window open on the .pm file, which describes what to do with those fields and what to do next. You also add in that same file extra methods for supplying your template with data while that page is being rendered. It's all quite natural and flexible.
And groups of pages can have common ancestors, below the top level app, so the nested hierarchy and "two level" dispatch is there through the proper use of SUPER. It's just objects. Objects work.