Attached is a second example of a potential problem, called ellipse_91_mm.svg. This file loads correctly in rev 13938 or newer, but it does not load correctly in rev 13937, the ellipse is too small. This is the inverse of the problem encountered above. In this case the document data was originally stored in units of mm, since it was made with a recent version of Inkscape. However the program is attempting to interpret the data as though they were in units of px, due to the fact that there is no viewbox, and due to the fact that the line which specifies the document units has been ignored in this particlar rev of Inkscape, which means that it will default to px, which is a mistake. This is the type of situation that you would encounter if you were importing an svg file from some other software program, where that software program had decided to implement the concept of document units, but had not implemented the concept of viewbox. What needs to be remembered here is that the implementaion of a viewbox has nothing at all to do with the implementation of different document units. It is entirely conceivable that a piece of software could implement one concept and deliberately refuse to implement the other one, because they are not related in any way. It is extremely unfortunate that Inkscape attempted to implement both at the same time, because it has led to a great deal of confusion.
	The point I would like to make is that both of these scenarios are equally important and they both need to addressed as equals, which in my opinion means that some user interaction will be required in order to make a decision as to whether to convert or not. All that is needed is a decision whether to use the declared units in the file, or whether to default to px.
	The second point I would like to make is that rev 13937 simply postpones the inevitable problem, without actually solving anything. In rev 13937 what is happening is a refusal to define a viewbox at all. If you look at the file after loading and saving, there is still no viewbox, which means it is still not compatible with current Inkscape and never will be. The only way to make it compatible with current Inkscape is to delete the document-units specification and load it into rev 13938 which will successfully convert it into the new format. There is also another potential problem associated with not immediately converting into the new format. In the bug report there were a number of references to unexpected changes in the size, when accidentally opening or using the document units dialog, see comments 7 and 11. These unexpected changes were occurring because the program was attempting to declare a viewbox for the very first time, and was failing because it was using the wrong units. It is true that this particular problem no longer occurs in current Inkscape, because the relevant code has been temporarily disabled, but sooner or later this code will need to be re-enabled again, and then we will have a major problem, because these inconsistencies will show up again. All we have done so far is to sweep the problem under the rug in the hope that it will go away, but it will not go away.
	It is my belief based on the above two examples that there is no automatic way for Inkscape to automatically deal with all the conceivable scenarios that may occur. I believe we will need to provide the user with a choice that needs to be made. The choice will be simply, do you want to use the declared units in the file, or do you want to default to px? Or alternatively the user can delete the offending line manually. The situation here is exactly the same as converting from 90 dpi to 96 dpi, at some point the user will need to make the decision for themselves, and all we can do is provide a user friendly interface for doing so. But the last thing we should be doing is to deliberately introduce inconsistencies into the current code base in order to compensate for an unfortunate design decision that was made more than ten years ago.