As a developer (currently not visible on SO as yet - though that's where I started reading along on Stackexchange back then), I think
there is perfectly nothing wrong here with "where... otherwise".
These are well-established ways of expressing circumstance in a problem (or more exactly, properties) akin to mathematics where "where..." is what to use to describe properties of an element in a problem and "... otherwise" may be used to denote "all other cases" after some have been described.
As already pointed out in great detail in this answer, there is obviously nothing wrong with this grammatically either.
The same would hold from a purely pragmatical point of view - such as to make oneself understood in exactly the way that would be on point and expected for the reader to get an unambiguous grasp of what they are being taught. In development (and mathematics), it's perfectly customary to use exactly this wording.
Although I'll add that my feeling with where you need is slightly off the track beaten by mathematic usage as that would be more strictly describing properties of parts of a problem rather than conclusions such as an implementation detail commanded by an ongoing design decision. But that seems to me a very minor difference in this case and does not command a change at any rate.
So the wording already present would be as close to perfect as it can get unless a completely different avenue were to be taken to describe the facts (and what would that be?).
The wording as is is perfectly correct in the field of software development - to go deeper, which I don't think is necessary, a look at vocational language could provide additional insight.
To go still deeper, a check for slight variation in register could be made, but again, of course depending on what is being aimed for, I wouldn't overdo it already having a perfectly suitable expression.
As for uniformity as a goal with respect to the other examples, experience from reading lengthy formal documents (where uniformity in clauses is sometimes required) shows that it can contribute rather negatively to the ability of the reader to keep their attention focused on their read. So it seems preferable to rather avoid perfect uniformity where not required because of sound reasons.
Stereotypical expression in a formal description of e.g. requirements may help the reader as they would be reading from a different angle - scarcely looking at the sterotyped parts of the text at all - as they are not learning but instead going through a (semantically) rather checklist type of document.
The ifs in the last example passage are perfect, too - that's a different kind of differentiation, so they are perfectly where they belong.