This is definitely an unfortunate side effect, thanks for pointing it out.
My suggestion would be the following: if an interaction does not specify a "version" it will replace all, and if it does specify a "version" it only affects that one.
I'll try to find some time soon-ish to implement this, but I can't make any promises.

As an aside/work-around, links can also /remove/ interactions, which should at least clean up your itps.

@pckroon I agree that this convention is the most sensible and easy(ish) to implement.

Conceptually, however, it would make a lot of sense to allow grouping of interactions (i.e. an interaction group - not to be confused with grouping them in the output). At the end of the day this type of dihedral potentials represent one interaction in the MD input as well. Changing just one term is a highly unlikely scenario and rather one wants to change all of them. GROMACS used to strictly enforce this by having them specified as interaction type 9, but that somehow got lost and now 1 and 9 are essentially the same.

In my view, if we were to completely abolish versions and just treat those interactions as a group, it would simplify a lot of the conceptual aspects of links. The code will likely be more complicated, which is why I am not pushing this right now.

That would indeed be the correct solution (I think), but does indeed cost a bit more code. I think I'll have to bite the bullet though. My previous suggestion has too many edgecases where what you want/need to do is either not possible or super hard. For example, when you want to switch from a "versionless" dihedral with a single potential to a "versioned" dihedral with multiple potentials.
The downside is that the parsing of interactions (not just for links!) gets harder, since it will no longer be line-by-line. I will cut myself some slack, and state that interaction groups must at least be within the same section, which should keep it manageable.