Embedded documents currently serve a smaller purpose that one would assume at first glance. I answer a lot of questions in the MongoDB-User group by telling people to "pull it into its own collection".

However, there are a couple planned features that'll change this. Virtual collections is one, but the other is the $ operator in field selection..which I believe is planned for 2.1.

Even as-is though, they are useful. The tag example is simplistic...let me give you a real case from mogade.com. We have a scores collection, which looks something like:

  {
    _id:  ObjectId('...'),
    leaderboard: ObjectId('...'),
    user: 'leto',
    daily: {
       points: 100,
       data: 'level 10',
       date: ....,
    },
    weekly: {
       points: 150,
       data: 'level 8',
       date: ....,
    },
    overall: {
       points: 300,
       data: 'level 15',
       date: ....,
    }
  }

We essentially store the user's top score for each scope (daily, weekly and overall). You could store a scope-per-document, which is how it initially was....but, that isn't how it's modeled and, it takes a lot more space (user and leaderboard get repeated 3x, along with the index which is on those two fields).

Also, I wrote about collections vs embedded documents: http://mongly.com/Multiple-Collections-Versus-Embedded-Docum...

Edit: I wouldn't rely on the age of a feature request as a sign that there's something fundamentally wrong with a design. Not everything can be top priority.

Well, Mongo does support queries on embedded objects as described in http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching...

It might not be exactly what you were looking for, but it could have the same outcome.

I'm currently working on an Android app, and started looking at couchdb a few days ago. I have to say I'm pretty intrigued, but I'm going to be dealing with location data, so the lack of querying has put me off for now.