MASON has always gone a long way out of the way to make sure that implementers don't
accidentally do things that will compromise performance. ... But as we attempt to do more complicated things, we reach a fork:
we can make things elegant and reasonably straightforward for the advanced coder but
allow greenhorns to shoot themselves in the feet, or we can make things complex and
difficult to implement, but ensure that no one is accidentally doing silly things. I think with
GeoMASON we have reached that fork and, indeed, moved past it.
...
Now, I do understand that updates to the QuadTree are quite expensive, so we might not
want to do them very often. In fact, I would perhaps suggest that one might want to lazily
schedule that update to the spatial index only when one has made an actual change to the
field contents.
However, I have an alternative suggestion: the REAL problem, I think, is that we're having to
put agents onto the GeoVector spaces instead of on more efficient, basic MASON grids or
continuous fields, if we want them to align to the underlying GIS landscape. ...