Navigation in Inspera tests

I am somewhat puzzled by the design decisions underlying the "disable navigate back button" in Design Settings for Question Sets in Inspera Assessment. From reading the documentation, it appears to me that this feature is either all or nothing? (i.e., if using it, it will apply to the question set as a whole, so back navigation is not possible anywhere). Is this correctly understood? And if so, why this all or nothing approach rather than something more fine granular?

Some typical use cases for this feature would be:

A) cases where question N+1 discloses the answer to question N. For this case, you would not need to disable back navigation in its entirety... actually it should not be necessary to disable navigation at all, since what you really need to prevent is not navigation but EDITING, i.e. the rule you need is: "After the candidate has opened question N+1, it is no longer possible to edit the answer to question N." Of course, the student should be given a clearly visible warning when trying to open question N+1 that this will cause question N will be locked, which the student then explicitly has to confirm to proceed, to prevent someone from accidentally going to N+1 without having completed their answer to N. The disadvantage of an all or nothing approach here is that the student will also prevented from navigating back and forth between questions N-3, N-2, N-1, or between N+2, N+3, N+4, where there is perhaps no valid pedagogical reason to prohibit navigation back and forth.

B) cases where a section allows use of some aids (calculator, books, software) that would render tasks in a previous section meaninglessly easy. One example could be in programming exams, if you want to use the new question type "Code compile". Another question genre often found in programming exams, especially in introductory courses, is code comprehension, where a piece of code with unexplained purpose is shown and the student is asked e.g. "what will be printed to screen when running this program?" The danger posed by a later "Code Compile" task where students are able to test their code against a test suite, is that a somewhat cunning student might easily use this to find answers to previous code comprehension tasks (e.g. pasting the comprehension code into the code compile window and just replacing the print with a logical test and assignment which would pass a test if the attempted answer was correct, fail it if wrong.) Again, what you want is not really to lock navigation but to lock editing, i.e. after you open the section with code compile tasks, it should no longer be possible to edit your answers to the earlier section(s) of the test. However, before you have entered the Code-Compile section, it may be totally fine if the student navigates back and forth between various earlier tasks, and similarly, after the student has started work in the code-compile section, it would be totally fine to navigate back and forth between the tasks that do belong in the Code-Compile section.

C) cases where you are using randomized order of questions to mitigate cheating by collaboration, especially in a take-home exam. Say, two students have agreed to sit together and collaborate during the exam, and the collaboration is rather asymmetric, one student being highly knowledgeable in the subject, the other aiming to be carried through the test by the classmate. Such collaboration will not be made impossible, but at least becomes a lot more difficult, if the two students are not receiving questions in the same order, and it is impossible to navigate back and forth to find the matching question in the other candidate's question set. In this case, maybe, a total prevention of any back navigation could make sense. Even so, it seems unfortunate that the feature is implemented by hiding user interface features (the test designer not only has to check "disable navigate back button", but also needs to hide the navigation bar and hide the table of contents, otherwise the feature will not have the wanted effect), as it would clearly be useful for the student for time management purposes to have a clear view of how many tasks there are in the question set, and how many one has answered so far. I.e., even for this use case, where a total ban on back navigation could make sense, you should not have to hide e.g. the table of contents. What actions the student is able to perform should in my opinion rather be defined in the underlying logic of the test, not in the presence or absence of user interface elements as such. I.e., sections or questions that you can no longer navigate to, could simply be greyed out in the navigation bar and TOC, with message "cannot be navigated to because you have opened question X" if the candidate attempts to click on it, thus still making it easy for the candidate to see how much has been answered and how much is still left to do on the test. Or, if allowing navigation but not editing, the answer is greyed out and the candidate gets the message "Cannot be edited after you have opened question N+1" if attempting to click into the answer to make changes.