Handlers that live in another stack

[WinstonJenks]

In order to implement something akin to a "shared script", I have handlers that live in scripts in buttons in another stack. So that other stack (let's call it stack "L") now has a bunch of behaviors needed by the primary stack, stack "A". Currently i have stack L in the Object Library folder, "My Documents/My Revolution Studio/Resources/Object Libraries" on Windows. The problem seems to be that the stack "L" is not found by stack "A" when stack "A" starts up, so the behaviors are not immediately available. It will start to work if I open the stack "L" and then set the behavior on one of the objects that uses stack "L" to itself. This apparently gets Revolution to go find stack "L". Once it has found it for one object, all the other objects with behaviors from that stack work too.

So there seem to be a couple of workarounds I can think of, none of which I have tried yet, which one do you think is best?
a) Add some lines to the stackFiles of stack "A". This should allow Revolution to find the stack with the behaviors in it. Right now, the problem with that is that the stack "L" is in a per-user directory, and other users won't find it. So maybe there is some extra code to reset the stackFiles to include all the .rev files in the Object Libraries folder at startup. Seems a bit excessive. [Just tried this--it works, but still not sure this is the best solution]
b) Keep the stack "L" in the same directory as stack "A". Easy enough. Handles the multiple user issue. But sometimes users keep their stacks in different directories. That makes the problem of having multiple stacks around and defeats the "library" concept.
c) Magically have Rev look for stacks in certain directories. Does it already do that? Maybe the PATH. Maybe the Externals directory? Maybe some other environment variable?
d) Import the stack "L" as a substack of stack "A". Then it can always be found. And there are no issues when the stack "A" is moved around. When the real library "L" is changed, have the user issue the command (i.e. click the button) to re-import the stack "L" as a substack again.

[shadowslash]

I personally prefer D which is to import it as a substack. It's what I always do with library stacks that I make. If, however, others have varying opinions I'd like to see them as well as I might learn from them.

[WinstonJenks]

For now, I have imported the stack "L" as a substack of the current stack. This is not ideal, because now the whole library concept has gone out the window, but it does seem to work, and that is an advantage over the previously tried mechanism.