While investigating a bug report on the PHP library, I noticed that the server allows DBRef objects to be stored with out-of-order keys. This appears to be legacy behavior, as it's present in versions 2.4 through 3.2 (all that I tested).

> db.foo.insert({_id:1})
WriteResult({ "nInserted" : 1 })
> db.foo.update({_id:1}, {$set:{ref:{a:"a","$ref":"b","$id":"c"}}})
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
> db.foo.find()
{ "_id" : 1, "ref" : { "a" : "a", "$ref" : "b", "$id" : "c" } }
> db.foo.update({_id:1}, {$set:{ref:{"$ref":"b","$id":"c","a":"a"}}})
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
> db.foo.find()
{ "_id" : 1, "ref" : DBRef("b", "c") }

Note: I'm not concerned with the shell's rendering of "DBRef" here (that's a separate issue for SERVER-9790 and SERVER-10777).

I would expect the server to raise an error here, since an embedded object starting with a non-$-prefixed field is not a DBRef. AFAICT, the mongo shell does some basic validation of its own for inserts to only allow $-prefixes for DBRef fields, but it doesn't enforce their order.

DBRef objects have a defined format, based on my definition in SERVER-12263:

DBRefs are objects whose first two fields must be $ref and $id (in that order). An optional $db field, if present, must appear third. Other fields may follow (they can't have a $ prefix, of course).

While we don't discuss "other fields" in our DBRef documentation, we do mention field order requirements:

The order of fields in the DBRef matters, and you must use the above sequence when using a DBRef.

The order of keys is also relevant to any validation logic. In fact, the related GitHub issue came up because the CRUD specification requires drivers to check that replacement documents not contain any $-prefixed fields; however, an exception is made for valid DBRef objects.