It will only reliably remap to orthogonalized values, if somewhere in both the export and import pipelines, there is a pragmatic that maps the most succinct decimal (text) representation to the closest binary mantissa and exponent (and especially vice versa).
Yes, with a note -- parsing always behaved that way in that parsing a rounded value was always producing a floating-point value closest to the string representation, we are only talking about printing.
Given proper printing functions, rounding a floating-point value to X decimals and then printing it should produce a string with no more than X decimals. That's because a 'proper' printing function is such that it prints the shortest possible *decimal* string that translates back to the exact same floating-point value.
For example, when we round, say, pi, to 2 decimals, the exact floating-point value that we get is something like 3.14000000000000012434... (proof: StringFormatNumber(RoundDecs(PI, 2), 'f20', '')). But this does not matter because if we just print 3.14, that, when parsed back into a floating-point value, produces the exact same floating-point value (proof: StringFormatNumber(CAST('3.14' AS FLOAT64), 'f20', '')).
Rounding to decimal fractions is safe that way, because printing, similarly to rounding to decimals, is also concerned with the shortest form in the decimal notation. Rounding to non-decimal fractions (eg, the infamous 1/3) is unsafe.
You can verify that rounding to decimal fractions does not produce extra digits during printing by running something like:
SELECT Max(StringLength(CAST(value/10000 AS NVARCHAR)) - 2) -- exclude '0.'
FROM CALL ValueSequence(0, 10000, 1);
The above produces all 4-digit fractions between 0 and 1, prints them, counts how many decimals are in the result, then finds the maximum number of decimals -- the result is 4, as expected (might be smaller, because values like '0.1000' are printed as '0.1' = one decimal, but not larger than 4).
So, if the function used to print floating-point values actually prints the shortest possible decimal string that translates back to the value, the printed values should not have any extra digits. If the software package that performs the printing is reasonably modern, it likely prints that way. That became the default way to print some time ago.