The 2Geom sync is almost done. So far I have identified two problem areas.
2Geom is now a lot more strict about what it considers a degenerate closing segment - it requires exact equality of endpoints, not just nearness to some arbitrary precision. This is of particular importance in paths where the last segment is curved. Because Inkscape loses precision when storing paths, bug #515237 now manifests on every closed path with a non-linear last segment.
https://bugs.launchpad.net/inkscape/+bug/515237
I intend to fix this in the following way: first, modify SVGPathParser so that it knows whether the last segment before 'z' was relative, and if it is, snap it to the final node with a precision set by another function call, 1e-6 by default; second, by making Inkscape output paths with the double-conversion library now integrated in 2Geom and always using absolute coordinates, so that there is perfect roundtrip between XML and internal representation. This will mean the removal of the Output Precision setting and a moderate increase in file sizes. The proper place for such functionality is in a separate export filter. As a bonus, setting the document unit to metres will no longer cause a variety of issues.
We discussed output precision briefly on the hackfest. Moving to full precision output with perfect roundtrip is the only correct solution and will enable us to avoid excessive recomputation of attributes in the SP tree, which is a performance win. If someone wants to get rid of extra precision - use an export filter. However, if anyone has a different opinion please speak up now.
The second problem is the transformation of elliptical arcs, as seen when manipulating ellipses in the selector tool. In some cases, the large arc / sweep flags are incorrectly set for transformed arcs. I am still looking for the cause of this bug.
The sync branch is at lp:~inkscape.dev/inkscape/lib2geom-sync - if anyone feels like looking for additional bugs, please do. I only did minimal testing on it.
Regards, Krzysztof