That is where extreme caution in any redesign needs to be exercised. The general approach you mention is the one Microsoft used for COM and the MS Word file format. This ends up blocking many of the more useful design patterns, and does things like tightly couple runtime functionality and efficiency to on-disk storage.
Hmm. I am not sure I understand this. What I was thinking about was this:
Currently every SPObject has a corresponding XML element node, for example every SPRectangle has a corresponding svg:rect element, and every SPPath has a corresponding svg:path element. From what I was able to understand, changing the type of the XML element node in response to some styling change (eg. change svg:rect to svg:path if it has markers or LPEs) is not easy, because you need to remove the old XML element node and create a new one. This will destroy any observers attached to the XML node, and in general one can't just 'transplant' them to the new node, because the observers might store the node's address somewhere.
What I thought about is to remove this link, and not store XML in memory at all. Saving would be similar to rendering: we would ask each object to generate its XML representation, and write it to the output file. One benefit of this is that we can change the element that is being written easily, and we can solve the flowtext issue (the flowtext object would "render" to a switch containing both Inkscape editing data and normal SVG 1.1 text).
Regards, Krzysztof