It might be worth defining the salient characteristics of a "Package Manager" so I can contribute from a position of knowledge rather than impede from a position of ignorance. A package manager to me is basically a way of installing an application that verifies unbundled dependencies are already present or fetches and installs them, as well. If the app is to be launched by a user the installer may create a short cut or add it to an already present launch menu. Packages that have nothing that is intended to be launched by a user don't make launch hooks.
As this discussion evolves I think the original request assumed that a subdirectory, by convention, only contained axillary files that were not not intended to be launched by a user. The request was to exclude those files from a launch menu that was built from a a disk traversal.
If the goal is to declutter one menu then the scriptMRUList already exists and will provide a less cluttered menu.
But the spirit of the OP could also be met by a) creating a way to identify a script as intended to be launched by user action and b) build a menu that only contained scripts marked as intended to be launched by user action.
We have ideas for a JSON format that could drive building a menu. We could assume that all script files in the top level of a third party local repository were user launchable so we could provide hooks to add or delete JSON data when a third party is installed or removed. Since the scriptMRU already has hooks to scripts that are run by users we can automatically add them to the menu when run. We could finally implement a Refresh option that confirmed everything in a local repository was in the JSON file (and added it if not) and that verified that a script mentioned in the JSON file existed and removed if from the file if not.
That sounds like small, manageable chunks that move us in the right direction and can be agreed upon or refined.
