Hi,
I don't want to disagree with anybody herein, and I can easily conceive the problem of interpreting "new features" in a version which didn't supported them, BUT...
The example of Pro/Engineer, which has been done previously, is not correct.
I don't know how things go now with Wildfire, but back in the times of versions 19, 18 and 17, PTC was very proud of the fact that whatever version of Pro/E would open whatever file created in the same "family" of products, i.e. they DID have backward/forward compatibility. I say that because I used this opportunity when I was at Univ and the Mech Dept was already on v.19 when I myself still was on v.17 at home because of a Student license.
Don't ask me how this was possible: I suspect that, when an unrecognized feature was encountered, it was unparametrized and the pure-CSG description used instead. In fact, opening a file coming from a "future" version could take a very long time.
OK, probably it's "a waste of time" (sic) for programmers to incorporate routines in order to do that, but the story I mention demonstrate that at least it is technically possible. Hystory tree, roll-back, etc are one thing; parametric description of a topology is another thing (mathematically speaking) and I really don't understand why it would be said that this latter couldn't be preserved, whichever the method / features used to create it.
Do you want another example? OK, ANSYS will import topology directly from UG, including parameters. Afterwards, you can even switch UG off but ANSYS will continue being able to modify the geometry using the imported parameters, as long as the topology is not violated of course. From Ansys' point of view, the TOPOLOGY is "dumb" BUT still parametric.
Regards