Besides direct editing, linking is one of the main vectors for end-user customization.
The triple script module system will also be extended to accommodate some kind of "libpacks"—analogous to shared objects in the world of "native" executables. These will be pre-compiled bundles that are still intended to be dropped into a repo and vendored like script modules, but the bundle will be an agglomeration of modules likely to be maintained and independently of the project and upgraded all-at-once.
Linkage model
The triple script linkage model can be understood in terms of C's, even though they are not the same model. To achieve sane external linkage, each module is allocated at most one privileged binding that can promote a name from internal linkage into the global scope. (Any other top-level binding is unprivileged, i.e. must come from an import.) This global scope is shared among all modules.
Name bindings are generally statically resolvable, through the use of import statements, with exactly one escape hatch: typeof checks. A typeof check allows the programmer to defer the binding of a given name to runtime, while keeping name visibility statically decidable. A program can thus interface with user-supplied modules/libpacks without the programmer having explicitly and statically linked against those modules themselves.