The system needs to know which modules are entry points that take the system provided modules and return an automaton and which ones are modules that are meant to be used as a library.
My latest brain wave here is to have a special folder that identifies the root of an "application" called .banjo. Tools can use this as a marker for finding the root of the application, just like how git uses .git.
Files in the root folder are assigned to "global" variables for that project. The contents of the file is the value of the variable, parsed according to its extension. For *.banjo that means a banjo expression. For *.txt it could be a string. For *.html or *.json or *.jpg there could be some sensible wrapping process making these types of data useful in the app. Folders are translated into an object where each file in the folder is a slot of the object.
Where there are two files with the same base name on the path, the values are concatenated with @ in search path order, then folders before files, and then alphabetical order (by suffix).
In this way the entire project can be combined into one big AST.
Importing libraries can be done by putting a banjo source file that has an expression that loads and returns the library. For example, a file somelib.banjo could contain the expression lib.link library({name = 'somelib-1.0'}) and lib.link library would presumably do whatever magic is needed to get that library as an object. A library would not share the same globals as a project it was imported to, but its calls to lib.link library would typically pull from the same place. This is similar to how python does things with its .pth files.
Literals can be translated into calls to certain functions in the scope, in which case there would need to be at least one predictable fixed path to find those literals.
A banjo environment should provide a tool that creates and manages the .banjo folder (which contains caches used by the compiler and dependency manager) and at the same time installs the core libraries into the project at project creation time. It can also help to search for and install/list/uninstall dependencies.
Having created a project, a tool is needed to evaluate expressions within that project - this is how a project can be "run". Or a REPL could be used. Different tools will interpret the result of the expression differently, whether to "build" or "run" or "print" something depends on the tool used.
When no .banjo folder can be found in the same folder as a source file or its parent, only the "default" core globals are provided.
The "main functions" are detected by evaluating each top-level variable and seeing whether it returns the appropriate type of result - the return of a call to main or whatever this function is eventually called.
Similarly, exported libraries can be detected by looking at their evaluated value as well, to see whether they are computing a library value returned by, perhaps, a function named library.