Right now, Parsoid does not guarantee no-dirty-diffs for any whitespace that is primarily syntactic sugar. Parsoid has treated newlines before/after translate opening and closing tags as primarily syntactic sugar and as such can add/remove newlines in a wikitext -> wikitext roundtrip.

However, it turns out that not all newlines before/after opening/closing tags are syntactic sugar. @Nikerabbit says:

Translate determines whether a unit is so called "inline" unit by checking if there are newlines inside it. Inline units may be wrapped using span tags to mark outdated translations or fallback translation. For block units we use divs.

But, all is not lost. As long as Parsoid doesn't add newlines in originally-inline-translate blocks ( <translate>foo</translate>) and does not remove all newlines from originally-block-translate blocks (<translate>\nfoo<translate> or any of those incarnations with a newline within the unit), i.e. if it doesn't change an inline unit to a block unit or vice versa, we can still get away with treating newlines as syntactic elements for our purposes.

This would require an analysis of the code and/or rt-testing diffs to verify that all is kosher. If it turns out Parsoid's html->wt code changes the translation-unit type and we cannot fix that, then we will have to add additional information in the wt->html direction (in an editable propert - either in data-mw or in some other HTML attribute) that we can then use in the html->wt direction to preserve that information.

Fingers crossed it is the former. :-)