Adam Solove has suggested a control panel museum. I think that would be a good challenge for wiki and a testbed for Method Control Loops. Conversation ensues. Adam's comments radically abbreviated.
Here is my admittedly superficial start on a control panel museum.
Control panels display diverse information and respond literally to a touch of a button. We will collect panels and sometimes bring them back to life with simulations.
I have a colleague who is building urban energy models in federated wiki. He has asked me for mechanisms that could do control loops as well as animations of their behavior.
To make progress it helps me to have a simpler problem that I can do any way I want rather than trying to do exactly what he wants. The museum will meet this need and maybe be fun in the long run too.
I've attached some notes on extending the Method Plugin to implement control loops. These could be handy for bringing airplane dials to life. I could also use a similar "markup" for state transition logic of, say, the telephone.
I'm a little vague on how an image gets turned into a live svg animation. Ideas? I wonder if d3.js could help?
Adam: Maybe you can describe the simplest possible example that would prove we had succeeded?
I don't have a clear notion of an end result. I do have a handful of features that a colleague, Michael Mehaffy, has been asking about. I don't want to build his application. Rather, I want to build the platform with which he can build his application. The control panel museum is a vehicle that may or may not work out.
On Michael's behalf I have expanded the Method Plugin to include unit calculation. Now I'm considering supporting closed loop calculations. I'm also interested in translation of Method calculations to javascript that will JIT for performance. I have code that will write spreadsheet formulas from Methods. That's a start.
Why bother? My pet theory is that I can make a number of small special purpose languages that are easier to learn and share than a general purpose programming language. This could make a difference, especially if there were to be contributions by someone who understands control but doesn't think of themselves as a programmer.
Say I have a control panel from a private aircraft. I could write simple formulas that would relate altitude and air speed to throttle and elevator. I'm told the relation is not what one would expect. Increate the throttle to go up. Operate the elevator to change speed.
I'm assuming these are simple formulas in a closed loop. If I wrote the wiki page that explained this relationship then I could use it to bring a control panel to life. Note that this is not the same a writing a flight simulator. Rather it is modeling a property of flight that is one thing pilots think about flying.
Now imagine I get the formula a little wrong. Imagine someone who works these formulas regularly wants to add a term or adjust a constant. Will these be obvious if looking behind the panel? Will the calculations include lots of units? I'm thinking yes.
Adam: What if we build this little demo of a car trying to stay on a track? worrydream 
Well, a quest for a weekend might be more immediately satisfying than a ten year accumulation of museum exhibits. I think it could fit nicely into federated wiki and could be an instructive reimplementation of the demo Alan Kay loves to show.
Lets think about how this might fit into plugins.
Alan Kay draws a track, builds a car, then shows that the feedback logic to drive the car on the road can be built out of his logic tiles. This uses some combination of sensors and actuators. His car can sense the painted road. His car can move and turn (like a turtle).
I suggest we do something similar. The Method plugin takes input bindings and returns output bindings. I have simple logic in the Reduce plugin that finds Methods and evaluates them in turn feeding the output of one into the input of the next. This "forward" calculation could control the car.
The new Car plugin would sense the car's environment, assemble this up as a collection of sensor readings, invoke the downstream Methods, then look through the final output for motor controls. The Car plugin would thereby implement the "feedback" logic I discussed in my proposed extension to Method.
The new Car plugin could be configured with car markup that could name and position sensors and motor controls of the car. It could also hold the car's image which it would position and rotate.
The new Car plugin would also find the first image to its left and use that as the track. This would happen when the car is double clicked. That is when the car, the track, and the control logic come together. If all the pieces aren't found, we have a false start and nothing happens.
I like this first because it puts Method computations in a feedback loop. I also like it because the car, the track and the control logic come from different pages, different sites even. Finally I like it because it is a federated solution to a problem Alan Kay likes to show. It makes everyone's cars and tracks and control equations intrinsically cataloged and shared. I don't think this would be so easy in his system.
It might help to think about a simpler problem.
Say I had a Dot plugin that would position a dot on a blank field then ask downstream methods to compute incremental motion of that dot. The Dot plugin provides bindings for X and Y and then looks for outputs DX and DY.
342 x 455 y
The Dot plugin decides how fast it repeats this process. It could also output its animation step time so this could figure into the calculations of DX and DY. I would write Methods like the following and expect the dot to orbit the origin at 100, 100.
x y 0.01 scale CALC (x-100)*scale SHOW dx CALC (100-y)*scale SHOW dy
This would give me digital readouts of DX and DY while the Dot plugin shows them graphically.
The Car plugin is just a fancy version of this with more variables floating between the model (Car vs. Dot plugins) and the control equations.
Adam: Your suggestion on the animating dot is spot-on. How does the method plugin currently work?
My approach to inter-page communication in wiki has been to try lots of things. Thus I have many examples that draw from each other and introduce specific variations appropriate to the task at hand.
The moving dot pokes at a particular weakness that could benefit from your experience. The issue is simple: how to setup and tear down event listeners as authors refactor pages or as readers retrieve them. The hard problem here is knowing which are the strongest forces bearing on the many available choices. Even poor choices are valuable now as they will expose their limitations.
Eval:
The basic strategy used by the Method plugin is to find an input hash (javascript object), evaluate its own calculations in that context, and then produce an output hash with its own new bindings. The Method plugin offers an eval method that takes input and output hashes as arguments and will perform computations.
I have written several other plugins that exploit this capability. The Rollup plugin fetches pages, looks for type: method paragraphs, and runs them sequentially through Method plugin's eval. The effect is to reevaluate a calculation based on initial conditions in the first input hash.
I have used the find & eval approach in the Reduce plugin that provides a slider on initial conditions and then reevaluates pages at an animation rate. Reduce also has a feature where it will translate the computation it finds into excel spreadsheet notation. This emphasizes the "universal" nature of the calculations and that wiki is mostly a collaborative refactoring editor for them.
Update:
Neither of these cause the redisplay of content beyond that of the Rollup or Reduce plugin. I have used general event broadcasts to synchronize displays. For example, the "thumb" event allows related Data, Method, Line and Radar plugins to track scrubbing of one or another's focus.
The Txtzyme plugin also has some hack to cause a Line plugin to accept new data when it flows up over websockets from attached Txtzyme hardware.
Forward:
A good step forward would be to get a dot moving with a rough approximation of the eval protocol, perhaps just written as a function taking input and output hashes, a stub for finding and evaling with a remote Method. I'll leave this to you.
With your permission I will copy some of these notes to a wiki page or two. I consider this our own experiment but in good open source style I'd like to be public about intentions and results.