From a distribution perspective, option 2 probably make sense (so you
have something like "gargoyle-scottfree" as a package). But the problem
there is that Gargoyle interpreters are intertwined with the Gargoyle
Glk implementation. You can't build and install garglk in such a way
that interpreters can link to it.
I imagine that the preferred solution for distributions would be to make
Gargoyle a fully-functioning development package, meaning installing
both libraries and headers to the system. This would make building
against Gargoyle much easier for independent interpreters. However, it
also means that we'd have to pay attention to ABI compatibility in the
library, which hasn't been an issue to this point. I suppose an easy
approach to that is to just increment the shared library version each
release regardless of what changes are made.
As an interpreter author, being able to link against a system Gargoyle
would be nice, because it means you can port/test your interpreter with
Gargoyle without having to integrate it into Gargoyle's build system.
Regardless of all of that:
I made the scottfree port solely to support Gargoyle, so I'd have no
problems adapting it to Gargoyle's needs, whatever those may become.
I wrote Bocfel expressly to work with Gargoyle (although it works fine
with other Glk implementations), so, as with scottfree, I'll happily
make any modifications needed for Gargoyle.
I'd be willing to maintain the unmaintained ports as well, which would
probably just wind up being a dump of the Gargoyle version at release
time, but if it satisfies third parties to have an "upstream" like that,
it's worth the small time investment.
In short, I'm fine with Gargoyle how it is, but if the general consensus
is that it's worth making changes to ease integration with some vendors,
I have no problem going that route, too, and I'll do what I can to help.