It is a basic lesson of software modelling that interfaces reflect architectural structure (or conversely that the API design influences the system architecture.)
Interscript maintains a current state analogous to a graphics device context: instead of pens, brushes, and canvases, the state can be partitioned into objects like the current weaver and current tangler.
Thus, as for graphics state, interscript provides a @select() command, to select objects into the current context.
Interscript requires clients construct individual tanglers, and provides the @tangler() command to facilitate this. In addition, some tanglers provide specialised tanglers for parts of the target programming language, such as strings and comments, or for extensions to the programming language.
On the other hand, weavers are generally not constructed individually by the LP author. Instead, the command line processor, or other launch script which invokes interscript, determines which documents formats the client desires: a default of none makes sense as this effectively turns the interscript process into tangle only mode.
The command line then constructs weavers for each desired format and hooks these weavers onto a multiplexor device, called a weaver loom, which delegates method calls to each of these weavers.
By contrast, typesetting different versions of a document requires that the user construct and manage a multiple looms. For example, if a document is written in one language and a translation into another is also provided, we need two looms, one of which is selected when a translation is available. When common text, such as code, is typeset, both weaver looms are selected.
It is necessary that the author construct these looms, and do so in a way that depends on the formats selected by the command line options. Furthermore, user command line options must be available to determine which whether to typeset the document in English, French, both, or neither: it is not the job of the author to make this decision.