> perhaps it's just latent hatred for that rather annoying framework

The reason why you need `set` is so that you know when to trigger `change` events. Getters and setters aren't going to fly if you need to support Internet Explorer. One alternative is the Angular.js tradeoff, where you're setting regular properties on vanilla objects and arrays ... but then Angular is going in behind the scenes and traversing all your objects and computing the diffs for you, every time a change might occur.

... in the end, you start to appreciate the transparency of avoiding getters and setters in JavaScript. It's a very nice thing that whenever I write `obj.a = b` -- I can know that that operation has no side effects, and won't trigger any outside-of-the-box behavior. Conversely, whenever I write `model.set('owner', 'Moe')`, it's nice to know that this is the point at which the rest of the app will react to that change.

And it also gets rid of the need to hide all your properties in an attributes collection. I'm not sure why you think that's good because it doesn't fire events.

And if you really need ignore properties, you could do something like this:

    var Person = {};
    Person.prototype = new Model;
    var bill = Person.create({ name : "Bill", email : "bill@example.com" }); //adds all using defineProperty and a watcher in get, set functions
    alert(bill.name); //Woo, alerts "Bill", not undefined!
    bill.name = "Bob"; //event fires
    person.special = "blah"; //wouldn't be watched as it's been added after creation
    person.addProperty("special2", "blah2"); //would be watched
    person.special2 = "blah3"; //events now fire with 'normal' access
    var person2 = Person.create({ name : "Bill", email : "bill@example.com", special : "thing" }, { ignore : ["special"]}); //special is not watched

There's a reason getters and setters have been added to js, and it's for exactly this kind of thing!