Thanks very much for your response
@Prof. Garfield; I appreciate you taking the time to come back to this. I'm relieved to hear that I misinterpreted some of your statements, or took them to have a tone you didn't intend.
It is true that I have a preference for modules where the details for the specific scenario are specified in the events.lua file rather than in the module itself, but that preference is relatively small, and, for all I know, others might actually find it easier to use modules the way you write them.
I agree -- ease of use (implementation), and being able to organize or segment code by "purpose" as much as possible, are probably the most compelling reasons for writing modules that are designed to be customized for each scenario. That definitely makes my modules different than true libraries, of course -- and I see a lot of value in libraries as well. Ultimately, I'm hoping that we can draw some (more) scenario designers without a programming background into Lua, and start to get their feedback on what approach has the lowest barrier to entry.
Perhaps an analogy would make my thought process clearer...
Got it.

Yeah, I guess your previous comments struck me as either arguing that my visegrips weren't a very effective screwdriver, or -- worse -- saying that I shouldn't have spent my time
building visegrips when that isn't what most people need. To use a different analogy, I felt like I built a Model T Ford, and you were plainly unimpressed because you want a Formula One race car. Well, sure, a race car would be great -- and I fully agree that what I've released so far isn't one. But there are also some people out there who are looking for a basic family sedan -- or an 18-wheeled semi truck! My perspective is, hey check this out, I built a vehicle with a working internal combustion engine. Now the door is open to iterate on that and introduce improvements to meet a variety of needs.
I do think that version 2.0 of my module will be going in the direction of making this a more generic tool -- in other words, the trend is towards the broader goal of "pathfinding" and not the narrower one of "supply lines". Since it's still a module that's intended to be edited by the implementer, though, you (or any designer) are welcome to tackle more advanced adaptations as part of that process. Perhaps that's another advantage to this design style -- it lends itself more easily to functionality tweaks that I
didn't anticipate or explicitly support.
However, to make the supply lines module do what I want (check if there is a path between a unit and a particular city), I need to be able to change the definition of "supply depot" every time the function is used. I may also want to be able to make it so that air units can't block the path...
I think the upcoming version 2.0 of my module intends to support both of these goals, although the code might not be structured exactly the way you envision it.
... and probably make battle groups block the path from a few squares away, so I would probably need to make changes to that part of the code as well.
Correct... "zone of control" is on the list of enhancements I have
not tackled yet. I had jotted down at least two different options for how a designer might want this to work in a functional sense, though, and now you've just raised a couple more: support for an
extended ZOC with a radius greater than 1 tile, and having different ZOC rules for a customizable set of unit types.
I should have kept in mind that while I was thinking of the supply module as an already existing tool that might or might not meet my needs, it was something that you created and, now that I think about it, hasn't been used in a scenario yet (at least to my knowledge).
Adoption is always going to proceed pretty slowly in a small community like this, so I'm not discouraged at all. I've actually received several private messages about this module from interested parties, which is pretty cool, so I'm optimistic that a scenario using it will eventually be released. One of those conversations was the impetus for many of the version 2.0 enhancements I've been working on.