In fact, one of them just came up: https://github.com/lexelby/inkstitch/issues/18#issuecomment-370301197. In that thread, we're talking about creating a PDF printout feature that shows the colors used in a design and the order they sew in. My original plan was to use the nifty, growing list of features in the command-line interface for Inkscape. My understanding is that these features are provided specifically to act as a "standard library" of functionality that can be used by extensions.

The problem with this is that extensions don't know where the Inkscape binary is. I can imagine writing code to guess, or perhaps look at the parent process, but trying to support Linux, Windows, and Mac sounds like a nightmare. End result: ink/stitch can't use this functionality.

Another rough edge is that extensions don't know where the current SVG file is stored on disk. We can access the file's basename, but not the directory. This is kind of annoying because ink/stitch wants to output a machine embroidery design file (.DST, .PES, etc). ink/stitch works around this by storing all of these files in a set "output directory" specified by the user, but this is obviously not ideal. Here's where one of our users/contributors discusses his desire for the design file to save alongside the SVG: https://github.com/lexelby/inkstitch/issues/75

I gather that Inkscape did previously store the directory, but it was removed due to privacy concerns. Perhaps the directory can be included in the SVG _only_ when communicating with an extension, not when saving? Another possibility is that the embroidery design output functionality could be an "output" extension, but I haven't played with that. I'm under the impression that the user would have to choose a folder and file name every time they wanted to save using an output plugin, which would be a prohibitively bad user experience for ink/stitch since it's common to repeatedly re-render the design file until you get it right.

"Dependency hell" is another big issue for extensions. Pyinstaller is very promising as a solution to this problem! I highly recommend mentioning it in the inkscape extension documentation. Trying to explain to users how to install python modules required by an extension is destined for failure. On Windows and Mac, the problem is even worse, as Inkscape bundles its own Python. It's very confusing for users that they can do `pip install -r requirements.txt` but then inkstitch still can't load its dependencies, because they didn't install the requirements in Inkscape's bundled Python. Installing modules for Windows's Python is especially complex.

Ultimately, we desire a completely smooth, painless installation process for our users. Currently, installation involves downloading a ZIP/tarball and uncompressing it in Inkscape's extensions directory. This is pretty smooth, and we could refine it even more by distributing it as a self-extracting installer. Anything more complex than uncompressing an archive risks losing users before they even try our extension.

One final thing: Inkscape's extension model is powerful and nifty, but of course it's also limiting. We've gone to a lot of lengths to work around this limitation, including popping up an entire UI of our own in one of ink/stitch's bundled extensions. Still, we constantly bump into the inability to integrate more directly with Inkscape, by adding tools or the like. I'm sure you've encountered this idea before. :) If Inkscape introduces such functionality, we'll be among the first to try it out.