Here’s my take. I’ve used Ember Data in anger and got a long way with it, including dynamic model attributes based on field model instances. Think generic product model with dynamic rich model fields described by models in a separate fields collection, along with implementing all kinds of constraints and calculations and field interdependency rules for sophisticated product descriptions/recipe’s and composition of products/parts, eg changing a user defined ‘area’, ‘difficulty’ field on a product can recalculate cost and quantities of multiple sub parts ad infinitum based on rules and complex calculations. Quite complex stuff that pushes the envelope. I also use embedded records for things that have a complex structure. It works
But I made my backend use flat URLs for everything , no nesting ever, which helps things work better with Ember Data or any api for that matter. Given all models have ids (I use v4 uuids) any nesting is just redundant. Ember data can be made to work with almost any data if you invest the time into understanding how the adapter and serializer layers work. Sometimes there are odd limitations in the interfaces and you may have hit one of those.
I have however found that Ember Data is just too slow to be practical in an ambitious application. Pull back a thousand items and you wait 2 seconds or more on a high end machine in the bowels of Ember Data before Ember even begins the processing required to update the view. I helped resolve some perf problems in Ember Data which doubled the speed in the latest betas but its still not good enough to be usable. The time from an ajax POJO to entering the render path should be milliseconds at most but its often thousands of time that in most of my cases even for relatively simple models. I had a colour database of some 40k items/descriptions with high cardinalty relatiknshils and I needed to cache a fair bit to make offline use practical. Its infeasible with Ember Data so you avoid it in those cases.
I’ve also implemented some sophisticated save/update orchestration that also deals with undo/redo within editing contexts. This was accomplished using controllers mediating models. It worked but its not as clean as I would like and took a lot of effort using buffered proxies. In the end Ember Data ruins things for you as you still have to push changes into model state in order to sync to the server and other parts of the UI update once the model changes. Then undo/redo gets complicated once that state has been pushed into the Ember Data layer. Layers and layers of stuff you wish wasn’t there.
Alas I have come to the conclusion my needs are better served sticking close to POJOs and a Flux like architecture using immutable.js to hold all application state. Its a different way of thinking about state management and well worth it IMO. Undo/redo practically for free both globally and for multiple even overlapping editing contexts, ability to serialize/store/transport all app state trivially, never have unwanted side effects or UI changing, control exactly when state gets updated and propagated vs backend/server synchronization. Its fast, simpler, more powerful and uses less memory. Above all I avoid models and just have state which components render. State mutation happens via a well defined semantic layer ‘at the top’, eg ‘add person’, ‘assign task’. Whatever state changes need to occur happen in that layer. I don’t need to deal with async fetch/relationship/promise issues down in components, views, templates and controllers like you need to do when using Ember Data since the state is pretty much a POJO. This is largely aligned with the ember 2.0 DDAU (data down actions up) approach accept for the fact components can pull state from services directly and components can send service actions rather than all state and actions being mediated by a parent component, which I think is flawed but that deserves a separate discussion.
If you don’t know what Flux is watch the facebook flux videos (but ignore their horrible public implementation) and perhaps check out reflux, fynx, barracks and other flux like implementstions for examples and inspiration of the basic idea.
I’m still refining how I do things but certainly Ember Data is not part of my approach any longer.