Please post TEXT as TEXT instead of images in different resolutions - it's TEXT!
The 4 examples with additional leading zeroes seem more like some changed formatting as they don't change the actual evaluated value mathematical - in fact, there shouldn't be any leading zeroes in scientific notation.
In the end it's IEEE754 imprecision of floating point numbers. The main underlying issue is that A3 only uses one number type "scalar" which is floating point - this can issues for whole integers sometimes not able to be represented correctly in IEEE754 i.e. have 2 end up in 1.999 or 2.00000001 or something stupid like this.
As for the attribtues: Yes, they got swapped around, but here the issue isn't that the editor does it but rather that your comparison engine doesn't correctly recognize the blocks and only shows the labels changed but wrongly thinks content of the blocks changed. Yes, correctly the attributes shouldn't get shuffled around once they're set and not further modified, but that's not how the editor engine works, don't think about the attributed as a fixed-order set of elements but rather a not-fixed list: The editor loads all stuff into memory - and on save it gets back serialized - in the order it's currently in memory. And if, for some reason, the not-predictable order list has changed the order - or rather changed the order the contained elements stored - then that's perfectly ok from a programmers point of view if all that matters are the presence of the elements and thier values but not thier order.
If you use some version control which has to deal with such results you have to change the version control engine to correctly deal with the blocks as one instead of splitting up thier unordered content. It's not the editor at fault but your version control.

If you have to rely on constant order: Write some simple converter which fixes all that stuff to your rules after export from the editor to keep the serialized data in a fixed order.