Yeah, it’s got to do with how I chose to expose my resources… it’s fairly fine-grained… what I really want to do is create an atomic transaction around a set of updates across the API, and it’s not particularly easy to do “straight out of the box”. Or, I could do it your way, and pack all the resources into one root resource, but that’d make ember data spit chips, I reckon.
By “not really transactionally atomic” I mean I’m using a REST API, and I can’t “begin a transaction” and then have seven or eight save operations happen on the REST side and then if there’s something wrong “revert the transaction” 
(ie the API isn’t tranactionally atomic. The architecture itself isn’t.)
Also, I’ve had issues with transactions in the past on Rails WRT transactions and locking. Deadlocks start manifesting when transactions appear, and that’s really crap. This is partly because of state, I reckon, but mostly because it’s not very intelligent about how it’s applying the transactions (take, for example, the “touch” function on relationships… that caused quite a few issues for me, deadlocks and all sorts of problems. I ended up rolling my own.)
But nonetheless, this half-assed way I’ve got it working, and there aren’t any issues other than the flickering on big object saves, and I don’t have to get all the objects after saving - at least it doens’t seem like it is. Data consistency isn’t an issue for me.
Yeah, I don’t think Ember will be able to work with ClojureScript anytime soon. Clojure uses mostly non-mutable data structures, so Ember wouldn’t really fit within its structure. There’s always Om (react.js with all the mutation functionality sidelined, and put into clojurescript)… but yeah… I’d have to do a lot more experimentation before tackling that particular beast.
But yeah, I feel silly ranting without helping out or suggesting anything… so… yep… 