Up spake Aaron Spike:
Because Inkscape is written in C++ / C, user-level macros would be extremely difficult to implement (well). Even with something like libguile, it would still be a lot of work.
Oh, why is that? (If you don't mind my asking.)
Since C / C++ lack an interpreted component. Therefore you have to use a scripting language (e.g. python, scheme), which in turn requires writing C -> scripting language glue. To do it `properly' (i.e. the user as access to every layer of Inkscape internals as first-class procedures in the scripting language), you'd have to write a *lot* of glue (say, five lines of code per Inkscape function).
This is compared to writing extensions for an application that is mostly written in the same language (e.g. emacs), where the user-written code is no different from the pre-written code.
Note that I'm not saying Inkscape should have been written in another language. I'm merely pointing out that to now *add* user-programmability will take a lot of work. I could, also, be dead wrong. I've never done it before, so this is all speculation.
Could the extension/plugin/scripting support be leveraged to sole problems like this one?
Yes, programmability would allow you to script such actions, easily. The difficulty is not the problem->solution->script arc, but the script->compiled-code arc (or so I believe).