As I write ever more html scripts to work within the sandbox provided by the Frame plugin I wonder if I just stepped up a level of abstraction I might write a transformer that reads and writes "sources" as we do in our lineups and offer a bit of uniform UI for buttons, lists and and other visual navigations. matrix 
I thought, what would I call such a computational plugin? We source and sink objects through the lineup so I search "source sink transformation" and found that there is already quite a bit out there for inspiration.
That doesn't mean that we wouldn't benefit from building a plugin with complexity similar to the "algorithmic drawing" markup of the Graphviz plugin. This is markup that describes the "visitor pattern" for collecting dot language content from wiki pages. about
I think the most valuable thing a new interpreter could offer is uniform and tolerant exception handling. I wrote a calculator plugin once that echoed the steps of the calculation and added footnotes (clickable asterisks) on statements that failed one way or another. This might be a good model for describing a "happy path" and then learning where deviations happen and leaving it to the reader-programmer to decide if they matter.
Aside: I've used a similar methodology in my "exploratory parsing". This would be an exploratory transformer that would encourage more structured content in federated wiki.
The heart of algorithmic drawing is the function eval that interprets markup (pre-parsed into a tree) as instructions for a breadth-first traversal of wiki pages starting from what is already available in the plugin's context. github
I'm not proud of this code except that it did manage efficient async fetches of wiki pages before I had a lot of skill in this area. I find async overlap is the dominant consideration in most of the scripts I write these days. Maybe we can make an eval that is beautiful?
See also Pages as a Team Player