The Reduce plugin will evaluate a sequence of interacting pages with input from a slider. Its weakness is that the computation is done off-screen so you can't see intermediate results on the pages that describe the calculations.
We've yet to reorganizing the codebase to make interactive refresh simple and robust. Here we consider postponing that, a prerequisite to Method Control Loops, and living with the selective update already included in Reduce plugin.
Spike
We could make a small variation of the Reduce plugin that feeds some downstream variable back into the start of a computation. That would make a loop that would "play" on its own, either damped to a value, oscillating, or wildly growing out of range.
My first thought is that it would leave the user out of the picture. Its like a video that you can't stop playing and that only shows you a tiny quarter of the screen. How would you know what is going on?
Maybe it would be enough for your immediate need if I did only this and left the animation for a later date. Then you could experiment with feedback loops using all the mechanisms we have in place now. I think it would be very tricky to use.
Let's look at what I've written about control loops already: Method Control Loops
I notice that this extension to the Method plugin doesn't run off-screen like the Reduce plugin. I think I was avoiding building on Reduce because I found its method of listing downstream pages awkward.
Markup
Let's assume a bit of awkward doesn't matter. Reduce already has a mini-language for describing variables to watch and ranges over which to slide.
I could change the slider such that it moves itself if the FEEDBACK option is chosen. If you want to grab control of an errant process, you could grab the slider and force a variable to a value.
The slider ranges from 1/2 to 2x the initial value of its initial condition. That seems good to start. If a slider "pins" at max or min, we could hold the variable at that value or let it keep going. I guess I would favor holding the variable in range.
Analog computers had hard limits and beepers that when of when a variable went out of range. wikipedia 
We could have markup that would configure this differently. Here are parameters that come to mind.
FEEDBACK variable-name -- name the variable to be fed back into the slider. LIMIT factor -- hold range to between 1/factor x and factor x initial condition. SUM factor -- the feedback will increment (scaled by +/- factor) rather than replace the current value. DELAY steps -- feedback will be delayed by the specified number of time steps
These are different, more primitive, than the controls I suggested for Method plugin. There I was trying to capture some of the scaling in the units calculation. Here I think we depend on simple scalars.
Generality
There are other limitations with this proposal. There is only one state variable, the slider. I show in the Reduce plugin about pages that you can have more than one slider but only one slides at the moment. (Again a limitation of wiki's update logic that I would like to lift.)
A classic feedback scenario is modeled by the Beer Distribution Game where each stage of the supply chain has a state variable (warehouse inventory). Wouldn't it be interesting to describe ordering policies for each stage on a separate page and then watch the trouble happen. wikipedia
Aside: It is common to ask students to play this game with different teams at different stages. It makes me wonder how we might play the game within the federation, each team at a different computer, each team on a different federated site. This might be possible without any new wiki capability. Students play it by passing paper invoices around between tables. We could play it by forking invoices in each player's wiki.