It monkey patches the entry points into javascript from the binding layer (some wrapping happens at a higher level), for the purpose of keeping track of the active zone. At that level we also wrap a try-catch block around all callbacks.
> Does a library (say, one that came from npm and not the core library) have to be zone-aware to function correctly with zones
It depends. Most modules shouldn't need any modification. However there are certain not-so-common cases (for example, when you're implementing a connection pool) that the module would need to be made zone-aware. It's necessary when the module wants to call a callback (or any function) in a child zone from a parent/ancestor zone.
Right now that's not very easy - you'd have to use a Gate (https://github.com/strongloop/zone#gates). W're working on an easier API.
> What we're doing is make it unnecessary to add error handlers everywhere and still get caught by surprising failure modes. If the zone catches an error it cleans up (closes resources, cancel operations when that makes sense) and then routes the error to the zone's result callback so you can handle it in once place.
I'm really unclear on how the zone library is doing the magical interception of errors. In the curl example you don't put error handlers on things. But clearly something must be. Does a library (say, one that came from npm and not the core library) have to be zone-aware to function correctly with zones? What does using zones mixed with libraries that aren't zone-aware look like? How much complexity does it add to the library to make it zone aware?