Background

So after diving into the subject of nested models/collections in Backbone.js and being very frustrated at how Backbone doesn't handle them, I eventually discovered a comment by Backbone.js creator, Jeremy Ashkenas on GitHub:

"The regular party line on nested models / nested data queries / change events on deep properties is available here: http://backbonejs.org/#FAQ-nested To reiterate, in brief -- Nested data objects are usually way less useful in JS than intelligently-organized "flat" data objects. Flat models can be more easily manipulated relationally, and trivially loaded from and persisted to relational databases. With nested models, you either reinvent querying into arbitrary JSON objects (like backbone-deep-model seems to do), or end up having to include something as large as JSONPath. Flat models make it easy to serialize and persist atomic changes to the state of your app -- folks using deeply nested models often end up sending huge quantities of redundant data over the wire. Basically -- we want to favor the normalized, relational approach to data modeling on the client side, over the "giant single global blob of deeply nested JSON" approach"

Confusion

...these comments by Jeremy confused me so much when I first read them that I quickly realized I must be missing something very basic. It turns out I was right. Hopefully some of the answers I came up with might help someone else in their decision making process about how to implement their Backbone.js models.

Clarity

"we want to favor the normalized, relational approach to data modeling on the client side, over the "giant single global blob of deeply nested JSON" approach

…what is not explicitly mentioned in that quote, but I believe important to understand (and which I did not previously understand), is that such an approach CAN be used with noSQL databases. That is to say that embedded/document-oriented schemas (e.g., that result in the 'single blob of nested JSON') are NOT the only schema one can use even with a noSQL context - a developer can instead create a flat schema by using references.

THE TAKEAWAY

Basically, Backbone is very opinionated about a preference for the latter data modeling schema (e.g., referencial). This may be for a good reasons as @jashkenas says, but it also means that developers trying to use Backbone's normalized-opinionated modeling with their document-oriented schema (which is quite a few people it seems) are trying to make things fit together that were never really intended to. Which is to say that developers would probably do well to either switch all their data modeling to what Backbone is opinionated for, or else grab the right extension for the data modeling schema they do use.

As a final note, I believe the example Backbone.js documentation gives in regard to nested models/collections only exacerbates potential confusion, ultimately. On the one hand the docs say that Backbone doesn't support nesting, but on the other is an example demonstrating and mentioning...nesting? Similarly, StackOverflow is full of many examples of people figuring out how to cram their document-oriented data schemas into Backbone's reference-oriented architecture. It can work I guess, but eww.

UPDATE: View the Reddit thread linking to this article for some interesting comments.