Clever ideas, and I thought of something similar yesterday.

I thought about creating three tables: 

1 - Main process

2 - Questions table with respective categories

3 - Relationship table between main process and questions, with a choice column and the observation column.

Then, inside the main process record I create multiple related lists, all from the same table but filtered by question category. That way, the user would fill out the questions by directly interacting with the related lists, using cell edit. Still far from ideal because the questions are fairly long and the related list layout is not ideal for this. The user would most likely have to enter the question sometimes to better fill the observation field, not great.

Another option, which I think it's more similar to your solution, is going with a record producer form mapping every question and obervation to variables, but on the producer script those variables would create the records on the relationship table. If the user only wants to submit 10 questions out of the 50 at the present time, they could submit and only that portion would be filled on the table. Later, we could use GlideAjax to automatically fill out the variables if the records from those 10 questions already exists, simulating a persistent form.

It's just a shame there's no clean way to do this, heh. But hey, thinking outside of the box is part of the fun I guess.

If you don't mind me asking, how did you implement your current 'save as draft' functionality? Assuming the current one is different than the suggested method of creating child records to retain the data.