I used the wrong phrasing. The ability to identify and modernize (internally or externally) any old version of the native file formats to the current version.
Although uncommon, the ability to downgrade (WITH DATA LOSS FOR INCOMPATIBLE FEATURES) to superseded file formats exists in many larger projects… including GIMP, MS Office suite, AutoCAD, etc.
I doubt that many with as small number of developers as this project are doing so. So it would not be reasonable to have such a complex function inside the core of Gramps.
But let’s take the worst case that our next application could not be made to work with old file formats. (For instance, if Gramps is forced to update to a version of Python that is incompatible with any BSDDB engine.)
Would it be possible to keep a plumber’s nightmare collection of headless CLI import/export modules (with the appropriately lower Python libraries) where you could pipe in the initial format, the modules update to their highest format, and then pipes it off to the next, more modern module. And that module does the same… until the version reaches the target format.
Such a plumber’s nightmare would be a separate project collection. It would be slow, ugly & inefficient. But it would keep potable data from becoming sewage. And do so with a minimum of user interaction.
What Gramps would have to do is: politely refuse when fed an old format, identify the format version accurately and suggest that the user download & use the right tool for that data version.
(The unrealistically ideal solution would be that Gramps would check if the tool was installed, if so, trigger a batch file which points at the problem source file and requesting the target version to be delivered & specifying where it would be delivered.
And once data flowed one direction in the pipeline, it could be made to flow the opposite direction for downgrades… with inevitable data loss expected.)