The internal transactions API will inherit options from its caller's opCtx, like read and write concern, but notably it does not inherit shard or database versions. If an operation on a shardsvr with shard versions used the API, the API's spawned commands would not include those versions and thus wouldn't obey sharding protocols, e.g. could read/write to orphan documents or during a migration critical section.

To be correct, the API should probably forward any shard versions in commands against the same namespaces, but it's unclear what to do if other namespaces are targeted by the transaction. No current uses of the API run in this case, so to prevent accidental misuse we should add an assertion to disallow using the API when its caller has a shard/db version and we can relax it if future if necessary when requirements are more clear.

This doesn't need to apply if the transaction is acting as a router because the router commands will attach appropriate shard/db versions.