You'll sometimes spot this when the Ctrl-X (or Ctrl-V) has to 'build' data and hasn't yet done so before you quickly Alt-Tab and Ctrl-V in another folder (or Paste is still a greyed option under the ContextMenu, even though the Cut/Copy
seems to have happened upon the selected source). And I've not seen it so much under *nix window managers, but I know Windows has often a bad habit of (so it seems) simultaneously deciding to trawl any and all selected folders/files to try to grab sidebar info like total file sizes or thumbnail image(s) which, in a move operation, can then cause the process to abort because some file is "still in use". The only thing actually using said file-object being the OS! Redo the move with the remainder and it progresses, maybe sticking at a later file, etc.
(And while it may even be due to adding up the intended move-space and the available destination-space, I'm not sure when the last time was that I've ever seen any system refuse to
start to do a copy under such circumstances. In fact, I fairly regularly (too often!?!) start a 'hopeless' move from one location to another knowing that I'm going to make an equally 'hopeless' move in the opposite direction, but that will (or
should!) incrementally create enough space to abort neither move. So I don't think any system actually tries to molly-coddle me and predict that I
won't happily deal with my own self-imposed problem, these days[1]. But perhaps there remain coded remnants of original one-at-a-time expectations, back when there was at least the memory of only ever a
single valid file operation at a time.)
As to 'hanging', maybe it has somehow stumbled while creating an idea for itself of exactly which (possibly non-consecutive) disk-sectors the source file is composed of, for reasons best known to itself. The exact mysteries behind it might be something the actual authors of the kernel/add-on code involved would understand (or an emergent property between different authors' works, might even surprise them!) but one tends to have one's own pet theories about why various glitches or hiccoughs occur within the largely uninspectable black-box behind the user interface that Explain All Known Facts, and sometimes I think I have an almost anthropomorphising intuition about what the system is 'thinking'. But I'd have to be fairly used to a given system to make it anything more than a inkling, and I'd be hesitant to suggest for sure what your *nix(-like?) system is 'thinking', even based upon my own *nix system experience, especially with so many possible base distros and variant distinct flavours of interface on top of them.
aka: Just One Of Those Things?
[1] And if command-line copies/moves regularly had an ETA (however clearly inaccurate they can sometimes be), I'd probably use them more than the GUI-equivalents. As it is, with something apparently to take 30 minutes to move from AAA to BBB and something else simultaneously to take 10 minutes to move from BBB to CCC, I can start to guess that I've got ~20 minutes until both are complete (unless I see those estimates vary wildly or I'm crossing different bandwidths of FIFO). Assuming that the starting free-space + movable chunks isn't likely to hit a temporilary stop in one direction or other. But that's more an art, of juggling, not a science.