This is exactly what I wanted to hear. Now does this behavior mandate that every element have an id attribute. I think Inkscape does this by default now. But it is not required by SVG and Jon Cruz has mentioned many times in the past that he would like to change our behavior. Are we talking id attributes or is there a unique id per element inside of Inkscape?
It is using the attributes. My reasoning was that if someone is working in a scripting console they will see all the return values and might just use them directly if they are human readable. Plus it's a lot easier to debug when functions return ("rect2353", "rect3454", "path3645") rather than (0x344535, 0x387574, 0x457684). I think that's worth the performance hit of looking up objects by their id attributes.
I wasn't aware that that wasn't part of the SVG spec. All of my knowledge about this sort of thing comes from opening up the XML editor and changing values to see what they do. If the id attributes get dropped I'll have to find another way to represent objects, hopefully one that isn't too messy.
How do we access elements that are placed outside of the visible SVG body and can't take part in a selection in Inkscape?
The proposed spec has get_parent() and get_children() functions that could be used. I left them out because I thought they might be confusing to users who don't know about the XML tree. But if there are things that advanced users might really need them for (like finding unselectable nodes) then I could put them in.
Nested transformations have been a bit of a problem in our current extensions because we are processing the raw XML and no one had put in the effort to write a tool that knows about these nested transforms. Its been so long since I worked with it that I don't remember exactly what the problems where. Are there circumstances when nested transformations will need to be taken into account to use your API or will it likely be transparent to the user because we are using Inkscape?
I just went back and tested this. In the documentation I warned about certain operations with transformations applied but I hadn't actually checked yet. Turns out Inkscape's sp_move_selection (Which all of my move functions relied on, manipulating and restoring the selection if necessary) actually fails silently if there is a transformation applied. After some digging though I was able to find a lower-level function that compensates for transformations (Although users will have to be warned that it may affect the transform attribute.)
So basically the answer is, no it's not a magic bullet that automatically solves the problem. But there are ways to deal with it, and if I'm careful, hopefully users won't have to be.