TL;DR: AutoGet* for multi-collection locking cannot correctly ascertain whether collections are unsharded without first having checked the sharding dbVersion. Since AutoGet* relies on secondary namespaces being unsharded, it's only safe to rely on the UNSHARDED response for secondary namespaces that match the primary namespace's database. Because the sharding protocol only supports single collection/db version checking.

------------------------

Kal explained that the UNSHARDED collection version is not reliable without the dbVersion check. The scenario is thus:

Shard A is the Primary Shard for database dbfoo. This means all unsharded collections in the database are located on Shard A.

An operation on Shard B runs on collection dbbar.bar (primary namespace) and 'dbfoo.foo' (secondary namespace).

On Shard B, AutoGet will run a sharding dbVersion check on dbbar, but not on dbfoo; later AutoGet will run a sharding collection shardVersion check on dbfoo.foo that returns UNSHARDED, which is supposed to be safe (note, only unsharded secondary namespaces are supported). Meanwhile, however, dbfoo.foo on Shard A may have become sharded, unbeknownst to Shard B.

Basically, UNSHARDED for a collection, without the dbVersion check, can just mean that the Shard that checked the collection isn't participating in holding data for that collection, not that the collection is unsharded.

------------------------

Note: the SBE $lookup multi-collection use-case is on a single database, so that can continue. We did recently use multi-collection locking in SERVER-62006, too, so we should double check whether it's a safe use-case: if shardVersion checks aren't relevant, then it should be fine – this is why we should flag guard multi-database locking, to allow it if explicitly declared OK.