Is there any limit to the number of follow up questions one can ask for a certain problem?
In a scenario where a user posts questions according to guidelines, then assuming this goes on for about 20 to 50 iterations, there should be an easier way to navigate between question-answers parts.
I suggest a breadcrumbs-like navigation (display the review number) or an implementation similar to that of GitHub commits. However, instead of a difference view, it displays a related review iteration.
I think you are thinking of the iterative process for an entire production size application, that is not what we do on Code Review.
If the process goes farther than like 10 iterations, it's a very large piece of code, and we would have told the user the first post that they need to break it up into several questions, or start with smaller pieces.
This moves us to the Conclusion that smaller pieces with 2-4 iterations is better than a huge piece of code that hardly anyone would read all the way through.
I don't think that your scenario is possible with the current Posting practices that we try to help new posters adhere too.
I do see your concern, but after 2-4 iterations the code is in pretty good shape usually, after that we would just be beating a dead Unicorn.
The answer to the first part of your question I think should be: As many as you need.
However.... be reasonable. You can't ask a follow-up to an unanswered question. You shouldn't ask a follow-up to a question you haven't marked an accepted answer to. And the code in your follow-up question should address every point in the answers provided or explain why those points weren't addressed.
In regards to the second part of your question, you can always go back and edit your old questions. Just edit each question to point to the one before and the one after it.
In light of Malachi's answer, and putting more emphasis on my be reasonable, if your code takes 20-50 iterations to get completely reviewed, it's probably way too big of a chunk of code for a reasonable CodeReview question, and you should consider breaking it into several smaller questions.
