> But even without looking at it, 

Please do look at it. 
Drop it in place of your existing OraFormat and using any diff tool see for yourself 
(Meld is a particularly nice graphical tool http://meldmerge.org/ )

> I'm thinking that sounds like a pretty substantial rewrite of the ora provider, 

It actually far simpler than it sounds. I hope if you look at it you will see that. 

> can we be sure that we don't introduce any issues with ora files, 

I've tested it a lot to get to work. The OpenRaster part is relatively uncomplicated, and the complexity is not so much in the code it is learning the OpenDocument standard and testing to see what the was the least markup I could get away with. 

(There is an ugly hack conversion of pixels to centimeters, I would not have thought was necessary until I tested it against Office, but that is on the OpenDocument side unrelated to the OpenRaster.)

> especially backwards compatability with existing Pinta-made ora? 

Old Open Raster files made in Pinta are not a problem. 

(As I mentioned before the old code treated a hidden layer the same as a layer having opacity=0 which was a strange broken behaviour anyway. I noticed this mistake after testing the sample OpenRaster documents. It did not make sense to try and work around that old broken behaviour. https://gitorious.org/openraster/openraster-example-files )

There are features of OpenRaster that Pinta does not yet implement. Some are relatively simple such as: locked layers; layer selected; the requirement of a mergedimage.png. Other are more complicated, such as the goal that OpenRaster should be able to pass through unknown information -- such as vector objects created by MyPaint .ora files. These missing features are an interoperability problem. 

The OpenRaster specification is a minimal specification, that simplicity is good, it makes the format easy to understand and implement but it is limited. This uses existing standards to extend it, adding more alongside the existing OpenRaster information, using OpenDocument as a superset of OpenRaster. 

At the risk of oversimplifying OpenDocument MUST include a manifest listing the contents of the archive, and MUST include content.xml and this code adds those things to the OpenRaster file.  (Making it both OpenRaster and OpenDocument compatible as a result.)  Following these extra requirements of OpenDocument benefits OpenRaster making it more interoperable, and more compatible with a greater set of tools. 

> (Also, having to rename to odg files afterwards is not ideal.) 

That is only a test to show compatibility. My intention was to extend the OpenRaster format, and recommend to developers that OpenRaster can and should reuse as much as possible of OpenDocument standards first. It was not my intention to implement OpenDocument Draw support.**

> Because of that I'm a bit sceptical to merging this into the Pinta core, but have no fear, we have an even better solution! This looks like an ideal candidate for a file format add-in!

The key reason I wrote this was to show that how OpenDocument overlaps and can be a superset of OpenRaster. 
If someone was to redo this as an add-in, I would hope at least some code would go into the core and be shared. The metadata code would be a good example of something that would be the same in both and pointless to rewrite but that requires various changes in Pinta ... 

... and brings me to the reason my changers were against Pinta 1.4, I couldn't get the latest version from Git or even version 1.5 to build. 
My priority was to write code, and to stay focused on OraFormat.cs and not other parts of Pinta. It is easy to forget that going from a user to a developer contributing a patch is a big step. Using Windows probably doesn't help. Getting a working build environment with the necessary dependencies and getting Pinta to actually build took a lot of time (and even when it seemed to be working I was faced by "MSB3247–Found conflicts between different versions of the same dependent assembly" which took more time to sort out, more time not writing code). While I'm interested to learn more about Git, but again writing the code was my priority. My next priority is implementing a Properties (Metadata) dialog. 


** I added a design note in the code but if a developer wanted to implement less crude OpenDocument Draw support then they would likely make different decisions, and need to write a lot more markup and probably quite a lot more styles code.