While working on making Model reactive, I have been refactoring mesa_signals. Below is a list of potential improvements.

mesa_signals is under active development, so PRs at this stage on any of these issues that are not in sync with the development I am doing, e.g., #3212, will not be accepted. Ideas and other suggestions are clearly welcome.

• Add a batch context manager; accumulate all signals until the context manager exists, for Observable.CHANGE, only keep the last signal, and also otherwise filter out any redundant signals. This might also solve the signal storm problem if observables are used for data collection.
• Add a suppress context manager; fully discard all signals until the context manager exits.
• Add HasObservable.subscribe; make it possible to subscribe at the class level such that the subscription is inherited by all instances. This would make it trivial to observe agents without relying on model.register_agent. The main challenge is that, while running experiments, it is critical that the observer (and by extension, the model instance) is properly garbage-collected.
• Resolve the dependency problem of @emit for @computed_property; @computed_property is an example of derived state. When evaluating, it will automatically discover any emitters on which it depends and subscribe itself to them so that any change in the dependencies results in a recalculation of the @computed_property whenever it is next accessed. The logic for inclusion in this autodiscovery is contained in BaseObservable, which is not used by @emit. There are at least two options for dependency injection: inclusion in the function signature of @computed_property or via an explicit track() call inside the decorated method.
• simplify and enhance performance of @computed_property autodiscovery of dependencies. Currently, on every call, it's fully rebuilt after first disposing of all parents. But subscribing is not cheap. So, it might be better to diff the dependencies and update only the changed ones. This also moves the subscription responsibility back into the @computable_property, which is conceptually cleaner.
• Consider some basic renaming: we currently have Observable, @computed_property, and @emit. In my thinking, emit is the most generic. It is just means there is a signal one can subscribe to. Obervable is also an emitter, but much more specific. @computed_property is derived from observable so it also a more specific emitter. In light of this, I am inclined to more generally speak of HasEmitters instead of HasObservables. In the docs, likewise, terminology might be made more precise.