The patch/diff module is working. I still haven't figured out how to use it to implement version control.
A simple Tkinter front end is under development for launching interscript runs, as an alternative to the command line launcher 'iscr.py'.
The current prefix and directory options for tanglers and weavers is effective but too primitive. The interscript source contains a currently unused installation frame which illustrates the mechanism intended to replace this. Interscript filenames will be extended to full URI syntax, with the protocol 'iscr' being used to designate vectoring of the output to a directory which is the value of a dictionary keyed by the 'machine' component of the URI, together with a trust level assigned by the client.
This mechanism allows the author to identify an arbitrary set of logical file systems into which output is put, and the client to map these logical file systems onto actual output points.
For example, the client will output stuff to a project development structure during testing. When happy, the output will be remapped to the installation structure. For example, html documentation could be automatically posted to the live Internet web site.
The main impediment to actually implementing this, is that to use the mechanism, the user will have to set up the installation frame to use interscript. It is very difficult to provide sensible defaults (other than 'current directory'). Doing this requires non-trivial programming work by the client, constructing or modifying the installation frame. This is not so bad if it is done from a GUI interface.
Move to Java. Because advanced interscript use requires a GUI based architecture to manage whole projects (as opposed to just processing a single document at a time), interscript is likely to move to JPython. This is advance warning to users: try to get JPyton running! It is also going to use a lot more advanced HTML features like javascript, style sheets, and other stuff which is currently a nightmare due to the lack of a standard Document Object Model for browsers.
Interscript current supports Internet Explorer DOM, in lieu of a standard. Although it is possible to incorporate some Netscape DOM features, the principal feature needed -- outlining -- requires dynamically setting the display style of an element, something Netscape doesn't support at all (at the time of writing, and as far as I can tell). Therefore, Netscape is treated like a dumb browser, and enhanced DHTML features will only work on Internet Explorer.
The emphasis on GUI interfaces cannot be overemphasised. The move to dynamic, fully featured, control over browsing the generated documents, together with full scale meta data generation to facilitate clients such as search engines and web crawlers indexing the documents, is considered crucial to getting a viable literate programmed system running. Use of Java AWT for the input side seems inevitable, as this appears to be the only GUI which is likely to be widely supported, standardised, and which also allows interaction between output and input by way of browser applet plugins.