In SBE plan cache key, we encode the number of elements in $in if there is no sort in the query and the length of $in is less than max scans to explode:

https://github.com/mongodb/mongo/blob/66d182d1e50b7bfa8866ca2c44917638a3758d79/src/mongo/db/query/canonical_query_encoder.cpp#L744

This is done because of explode for sort SBE plan will have the number of branches equal to the number of elements in $in.

SERVER-83777 made it so that if $in length is greater than max scans to explode (we don't need explode for sort), then $in length is not cached.

SERVER-83712  makes it so that if there is no sort in query (we don't need to explode for sort), then $in length is not cached.

From Storch: One idea for how to implement this is to have some kind of runtime explosion. That is, the cached plan itself would not necessarily contain all of the necessary branches beneath the SortedMergeStage. When the plan is recovered from the cache and the input parameter values bound in, we can create the correct number of cloned ixscan branches beneath the sorted merge, each referring to the correct (lowKey, highKey) pair from the runtime environment.