Compound shard key with _id field
You'll need to rethink your shard key approach.

As at MongoDB 3.2:


All fields in a compound shard key must be present in all documents and will be immutable (i.e. the shard key for an existing document cannot be changed).
A hashed shard key is based on a single field, and does not support range queries.


It generally makes sense to have a shard key that supports your common queries so they can be targeted at a subset of shards with relevant data, but this doesn't appear to be possible in your case as both foo and bar are optional fields.

If your _id field provides good cardinality (i.e. large number of values) but is monotonically increasing (eg. default ObjectIDs) you could consider a hashed shard index on the _id field for good write distribution. The hashed index wouldn't support your common read queries (unless by specific _id values) so you would need a secondary index for your queries on foo and bar (i.e. {foo:1, bar:1}). The recommended secondary index(es) and order will depend on your common queries and sort order.

For further background information I suggest reviewing:


Considerations for Selecting Shard Keys
Use Indexes to Sort Query Results
Optimizing MongoDB Compound Indexes