So long as there are features that are prohibited, limited, or that underperform on a sharded cluster, it might be nice to let people spin up standalones and replica sets that prohibit or warn about the use of those features, so that the developer can ensure that they're not relying on features they'll have to give up when they choose to shard.

I'd envision this as a command-line flag that either disallows or logs when an application tries something that doesn't play well with sharding.

Broadly speaking, there are three categories of things I could imagine flagging
in such a mode:

1. features that mongos unconditionally refuses to route (e.g., db.eval, $snapshot queries, $isolated updates, etc.),
2. features that are disallowed on sharded collections because they play poorly with sharding key (unique indexes, single-document updates, etc.)
3. queries that don't incorporate shard keys. [This might be overly broad. Perhaps it ought to be queries that don't incorporate shard keys and that supply a limit and/or that use an index? Basically, things that are attempting to be selective (and so are presumably things for which users want or expect low latency), however that might be operationally characterized.]

For the last two to work, it'd be necessary to configure a mongod that was started in the appropriate mode with fake shard key definitions for some collections. I have no opinions about how that ought to work, other than that it'd be nice for such fake shard key definitions to be both persistent and easy to delete in a non-sharded mongod.

Observation: even if the general "fake sharding mode" idea were implemented piecemeal (i.e., not everything that ought to be caught were for initial iterations), it might still be incrementally useful.

Documentation changes needed: if implemented, must be documented.

CAP Verification: if implemented, then it ought to be tested.