The technical possibility depends on your shard key index rather than zoning, but this is a scenario you definitely want to avoid.
The _id field uniquely identifies a document within a given collection on a shard. If documents have the same _id values on different shards, attempted migration of those documents to the same shard will result in a duplicate key exception. Non-unique _id values are also likely to lead to logic errors for developers or tools assuming _id is a unique identifier.
If your _id values are using default ObjectIDs, the chance of collision should be extremely low. However, if you are setting custom _id values and sharding without using _id as the shard key or a prefix of the shard key, you need to guard against the possibility of creating duplicate _id values.
If the _id field is not the shard key or the prefix of the shard key, _id index only enforces the uniqueness constraint per shard and not across shards.
For example, consider a sharded collection (with shard key {x: 1} ) that spans two shards A and B. Because the _id key is not part of the shard key, the collection could have a document with _id value 1 in shard A and another document with _id value 1 in shard B.
If the _id field is not the shard key nor the prefix of the shard key, MongoDB expects applications to enforce the uniqueness of the _id values across the shards.