I've run into it myself and I've seen many other people run into it; making changes in workflow and getting a new version for every single change.

My solution was to use an SDK script to check the document out and make all of the changes in the script before saving to avoid this scenario, and I've seen other approaches as well like working with a temp document then overwriting.

I know it would be tricky since you'd need to revamp how the workflow activities handle saving changes, but I'd love to see some kind of grouping for workflow activities that would allow us to make multiple changes to a document as part of one version.

What I'm imagining is some container type activity where we can set the target entry, define a single version comment, and put our "grouped" activities together inside of it so they all occur as part of the same overall change.

For example,

I add my "version container" to the workflow and target the starting entry.

Inside of that I add an activity to set metadata fields, one to add a text box or other annotations, another to delete an annotation, maybe apply a stamp or redaction, etc.

Perhaps instead of treating it like a container where you drag normal activities in, you have to add them through a menu in the properties so that you can limit what can be put inside and ensure they all target the same entry, but anything that allows the grouping would be fantastic.

Then, when the workflow runs, it checks the document out at the start of the version block, makes all the subsequent changes, and saves at the end so you only create one new version with all of the contained changes.

An option like this would be incredibly useful for me because I could eliminate several custom scripts, and for people who don't necessarily know how to write SDK scripts to bypass this behavior, it would reduce confusion for the users who see 2 or 3 different intermediate versions generated by workflow and don't always know what that means.