Miles Silberling-Cook

It's probably fine to keep this component-only for now, considering that resources don't currently support hooks (so the applications are pretty minimal). Eventually it seems like resources are going to...

> This shouldn't be required. The data is only immutable while it is stored on the entity, so remove/mutate/insert can be used to avoid any cloning. If that pattern is...

I'm a strong proponent of "immutable". It's the right level of technical precision for the users who will know they want to use this, and those who are unfamiliar will...

I'll take a look when I get time. This code probably has not been as fully tested as it should.

I don't have opinions about the default behavior for node. We could add it as a required component, and maybe either ignore or non-blocking make sense.

Personally, I'd rename `track_change_detection` and gate all tracking behind it. For hooks, that's a bit harder. Ideally an optional `Option` parameter, so that people don't have to litter their code...

> I do have a couple suggestions that should be tackled in a follow-up PR to address some of the ergonomics issues we're starting to collect with track_caller. But as...

I would like advice on how best to document this, since it doesn't really expose anything publicly by default, except for perhaps the new `Traversal` trait (which I am writing...

I resolved all the issues identified in the reviews and I was in the process of porting over the examples from `bevy_eventlistener` when I identified a rather large footgun with...

I have not yet profiled. I am expecting it to be somewhat slower. Will port over the eventlistener stress test once I fix the footguns.