Not sure if it's relevant - I ran into just one case: https://cs.wikipedia.beta.wmflabs.org/w/index.php?title=Gramofonov%C3%A1_deska&diff=4410&oldid=3972. A rejected link still resulted in a saved edit. The issue is not reproducible though.

Note: Currently (wmf.15`) after a user has rejected all recommended links, a user will still be presented with "Save your changes" dialog. Add image tasks do not have it. Should the Publish dialog be dropped for Add link too?

either by undoing a hack and having a rejection process that does not rely on saving

Currently saving on rejection is used to:

• Treat rejecting and accepting recommendations similarly from a workflow perspective (even though only one of them should result in an edit, they both mean the user "submitted" the task, so we want similar UX).
  • Show the save dialog, or something looking like the save dialog, on rejection for Add Link (we don't show it for Add Image as there is a dedicated reject button, wile for Add Link the user reviews multiple links and it's a rejection if some of them were rejected and none of them were accepted).
  • Exit VE, update suggested edit session state, and trigger the post-edit dialog after rejection (I guess exiting VE is not strictly necessary, but it makes the UX more consistent, and the post-edit dialog behavior more predictable from our perspective). We already do this since the postEdit hook doesn't trigger on a null edit, but we'd have to reorganize the code a bit.
• Create a new rejection API that takes task information (like the image name) and triggers the structured task type's submit handler (which creates a Special:Log entry, for Add Image an EventGate event, and does various invalidation like removing the CirrusSearch tag, resetting the user's task cache, adding to the Add Image temporary exclusion list, deleting from DB cache in the case of Add Link).
• Adjust instrumentation.
• Increment the grafana tasktype save counter (now done by the VE postsave hook).

So rewriting it would not be simple. OTOH we could probably remove a bunch of hacks (like StructuredTaskArticleTarget.getSaveOptions).

or by preventing the save

Some options here:

• Update VisualEditorApiVisualEditorEditPreSave so it can change the wikitext, and update the wikitext to be the wikitext stored in the revision table (or provide some other means by which the hook can signal to the VE API that it should not make an edit but pretend it did). This is a huge hack, and fragile. If I were the maintainer of the VE API code, I wouldn't want it.
• Use the VisualEditorApiVisualEditorEditPreSave hook to return an error if the received wikitext is not the same as the stored wikitext. This can fail in some extremely fringe cases (when the pre-save transform isn't idempotent) but in practice it's fine. Since this will make the visualeditoredit API return an error, we'd need special handling for that on the frontend (if we care; since this will be rarely needed, and a confusing error message is less problematic than a confusing edit, we might not).
• Use a lower-level edit hook which allows changing the content, such as ParserPreSaveTransformComplete. There is no clean way to identify GrowthExperiments edits at this point, but we can rely on global state. In terms of capabilities, this is the best option (allows forcing a null edit, instead of a failed edit) but feels super hacky. Would probably need to be re-done after parser unification.
• Use a lower-level save hook with access to the edit summary (e.g. MultiContentSave) which is a relatively clean way to detect structured edits. These hooks can only prevent the edit, not turn it into a null edit, though.