We're extending wiki to support more interactive data manipulation. When this started getting complex I suggested we look for an approach that is maybe less ideal but easier to get right and keep working. riot 
Early on in the project I chose to let some of these update issues slide. I knew I was doing a lot less than would be possible. I also knew that intense pub-sub over the network was fraught with edge cases. I sought a system that felt kinda modern and still kinda "cgi".
Adam Solove opined that I had cleverly avoided most difficult problems. I took that as a complement.
This project has been rewarding for me because we don't have the pressure of a commercial operation to make and keep promises. We can wait for great ideas, even if they seem a bit like cheats at first.
(A few days pass. We resume discussing bind. I quote.)
Plugins register for events emitted from various sources within wiki. Here we consider coding strategies based on the lifetime of emitters and the handlers that listen to them. Examples from Graph plugin.
Before I left Tektronix I had built a IC CAD system in Smalltalk. Absolutely everything was incremental. If you typed or clicked, an object was made and that just lived in the system as long as it was needed. So registering and unregistering was the dominant logic.
A year later I was writing cgi scripts in perl. The most amazing thing was I didn't have to register or release anything. Once my script was done it all disappeared.
When I say this wiki is cgi-like, that's what I'm thinking. I like that we are working in this trade-off space. There are many good approaches. Each one favors a different style of computing.
.
I quote these excerpts from chat thinking they might provide a good example of engineering deliberation. This could just be weeds in the garden.