shutil.move() has always fallen back on copy/unlink if os.rename() fails. This used to be clearly documented to account for the behavior of os.rename() in Windows, but the details were obscured over multiple rewrites. Currently the documentation makes it seem that copy/unlink are only used if the destination is on another filesystem.

Anyway, falling back on copy/unlink is sub-optimal as a move operation [1] and should be avoided wherever possible. It would be better to use os.replace() instead of os.rename(). This expands support for an atomic move within a filesystem, and it avoids the need to modify the documentation, except to reference os.replace() instead of os.rename().

---

[1] As implemented, a copy will not retain the source file's alternate data streams, security descriptor (i.e. owner and access/audit control), file attributes, or extended file attributes. There are additional problems with reparse points other than symlinks, but that's a difficult problem. We don't support raw copying of reparse points, or even high-level support for creating mountpoint (aka junction) reparse points. There's _winapi.CreateJunction, but the current implementation is just for testing purposes.