Nice, I made something really similar but found it had a bunch of issues. Some of which I don't see addressed here.

When setting an object or array, it will always trigger since the equal comparison will return false even if they have the same { key: value } pairs:

    target[property] !== value

Speaking of which, sub-properties are not being listened to from the root (only if manually listened to on the sub-object):

    obj.foo = { bar: 'baz' }; // triggers
    obj.foo.bar = 'whatever'; // never triggers the base listener

The only realistic automatic way to listen to them is to add a trap for the get, which will proxify the return value if it's an object or array. This has it's own set of errors and turns into a nasty set of edge cases, which is the main reason I never got to release what I was doing. I see in Icaro you Proxify it manually and adding some props on the setter, which leads to this not working as expected:

    const obj = icaro({ foo: { bar: 'baz' } });
    obj.foo.bar = 'baz2';  // Nothing triggers

The array example is a little weird.

    // no events here
    arr.map(v => v + '-meh')

Since `.map` doesn't mutate the array in the first place, surely no one would expect observation events to occur anyway?

Isn't this just queuing up the actual, real work on the event loop?

Of course its faster to call setImmediate a bunch of times to defer work, than it is to actually DO the work. It is useless to compare a synthetic benchmark for what is fundamentally a task that involves drawing something to the screen, without measuring the time it takes to finish all those tasks. The actual performance will, of course, be determined by how many DOM mutations are occurring, and the relative layout complexity of each. There will be a benefit for lots of really small, expensive mutations that could be batched together, but who designs their applications like that? Oh, wait...

At least, that's my understanding of looking at the source for a few minutes. Maybe I'm missing something, but I don't see any real algorithm at work here, just work that is shifted around to make a benchmark look good.

A better benchmark would be to use this in a real world, non-trivial use-case somehow and measure the framerate. But I can save you the effort: It's not going to win out over a well designed application that does direct DOM manipulation. Period.

Last time I tried Proxies, their performance wasn't very good. It would be great to see a few benchmarks.

What advantages would this give you over using persistent data structures [0] with memoized selectors? When using immutable data structures, you can shift the responsibility of providing updates up to the caller. In my experience, that usually means code that's easier to debug and test.

[0] https://en.wikipedia.org/wiki/Persistent_data_structure

If this is meant to target modern browsers, what's the use of this check and fallback for IE's obsolete API?

    if (global.addEventListener) {
      global.addEventListener('message', onGlobalMessage, false);
    } else {
      global.attachEvent('onmessage', onGlobalMessage);
    }

I think I have a smaller one https://github.com/albertbuchard/promets-moi