Done today:
When register handler, returns an object. This object supports suspend, resume, and printContents. (Suspend will prevent the handler from firing, resume allows a suspended handler to resume firing, and printContents prints the pattern data that causes a callback to fire.)

--Still need to print the callback in printContents.
--May want to make it so that all handlers are accessible through some type of system array. (If you lose track of the object you assigned to the handler, currently, you're out of luck.)
--Probably put off until users demand: make it so that can reset the callback from the handler object.

Bugs fixed:
--Can match against values again. (Needed to create persistent objects for values in JSPattern.hpp.)

Decisions made:
--Will not support multiple senders to match in event handlers. Reason: users can always do dispatch within a function, and membership that would match an event handler is likely to be dynamic. Downside: could lead to some bad coding practices. For instance, someone might iterate over an array, creating separate handlers for each potential sender in the array. These handlers would do the same things: would be difficult to modify, inspect, and play with.

--Holding off on a "default" handler. Default handler is invoked if no other handler matches. For now, not adding it because no concrete use case. Additionally, makes difficult to reason about what happens if users do some additional checks in their handlers that aren't relevant.

--I'm leaning heavily towards dispatching all handlers with matching patterns. Ewen mentioned doing something along the lines of strongest match, but that seems like a can of worms: how do you measure strongest? If you say that it's the most fields, then you can still have ties.

Current status:
--Broadcast works. (__broadcast(obj))
--Can send specific messages through system.addressable array.
--Objects serialized. (Can pipe around code with this + messaging)
--Pattern matching (minus prototype) works.