The way your database is set up the portals (except the question one) are keyed to your Global Display Keys table
All you need to do to display new data in the portals is to change the values in the GDK table.
Now Im not certain if the respondant IDs are sequential or not but if they are you could simply
use buttons that (i dont remember the table and field names exactly off hand)
Set Field (GDK::Respondant ID; GDK::RespondantID + 1)
Refresh Window [Flush Cached Join Results]
Subsequently you could use Respondant - 1 to back up on a seperate button. These buttons dont need to be in a portal.
If you have the related name field on the layout you should see the name change to verify you have the right person.
You shouldnt need a script to clear out the codes it should clear when the GDK values are changed. YOu can add the Refresh Window script step to the current scripts that change the values. You shouldnt need it but it cant hurt.
As to the code list you shouldnt have to go back to see response unless the GDK responseid field is somehow being blanked out. You should just be able to click the dropdown list again in the code values portal and it should show. these XREF codes should be keyed to the GDKSurvey and GDKQuestion ID only and not to a response code (this is what drives the conditional value list) You should only have to click back on the Code tab and then return to coding.
the respondents are not necessarily sequential. They do go in order, but there can be several numbers skipped in between. Is there anything else I can do?
You could design a new similar layout based on the respondant table the way you set the global display keys would be different for some of the fields you could then use the "book" to scroll through the records. (the main differences is you wouldt use the dropdown for the GDKrespondant id and you would use an OnRecordLoad Script trigger to set both the GDK Survey ID and the GDK ResponantID
Much of the rest would remain the same.
Before you go try it. Spend some time understanding how the GDK fields get set and what their functions are in the current layout. Imagine how they will change when the layout is based on a different parent record.