What originally drove me to this issue is related to GODRIVER-877. However, rather than Go's non-deterministic maps being used in a filter expression, the use of maps in my actual data that I was inserting (and querying) was an issue.

Currently, you can create data that takes advantage of a map, for example:
 

type Project struct {     ID        primitive.ObjectID `bson:"_id,omitempty" json:"id"`     CreatedAt time.Time          `bson:"created_timestamp" json:"created_timestamp"`     UpdatedAt time.Time          `bson:"updated_timestamp" json:"updated_timestamp"` 
    Disabled bool `bson:"disabled" json:"disabled"` 
    Deleted bool `bson:"deleted" json:"deleted"` 
     ProviderArguments map[string]string  `bson:"provider_arguments" json:"provider_arguments"`
}

 
 
With the above example, when the data is inserted by mongodb-go-driver, it looks like it may take the same unordered/non-deterministic methods that Go itself does.
 
The problem with this is let's say you want to compare the entire provider_arguments field, by passing in your own map field... this isn't possible as that non-deterministic logic will intermittently fail.
 
With BSON, and order on insert mattering, but the comparison and insert essentially being random, I believe the use of maps should be discouraged, and noted that this will not work as intended (and how Go's behavior will make querying difficult).
 
It's possible to use something like provider_arguments.<field> in a bson.M/bson.D, but this is very hacky when the the keys aren't hardcoded, and may lead to potential security concerns without proper validation of input keys (e.g, my provider_arguments are coming from parsed data from HTTP GET parameters, and you have to join them together).
 
Thoughts?