This is an extension to SERVER-3562. That fix caused the 'movePrimary' command to not move any collection data for sharded collections. Because 'movePrimary' (or 'clone') does not take out a write lock, it is possible for users to try to write to that collection while the clone is in-flight. If they do so before the metadata is updated, the writes can be lost.

The long-term fix would be to lock all of the collections being moved by 'clone'. As a short-term fix, I'd suggest having 'movePrimary' return a warning if it detects any unsharded collections in the database being moved.