> That's not just Windows, it is the way the copy/paste model works absolutely everywhere outside Mac's Finder. And there is a clear reason why it makes sense,

> That's not just Windows, it is the way the copy/paste model works absolutely everywhere outside Mac's Finder. And there is a clear reason why it makes sense, and why the Finder way is just bad UX: the decision about what happens in location X should always be done when you are in location X. Hmm, the first part isn't convincing. To me that sounds like "everyone else is doing it" and not much different than arguing between left side vs right side driving, when there could be a third way, like teleportation. Not saying Finder is quite that much of a shift, but Finder's method does have semantical differences, and not just "hey we're cmd+n/m for cut/copy". As for the second part, I think that's an intriguing argument, but "bad UX" seems like a stretch. If it were truly always decided in location X, would you have to return to location X to cancel your copy/cut? No, because that would be far too strict. It also depends on what your mental model is of what has been decided at location X. On macOS: I have decided I want to manipulate the data in this file at location X. I can decide to copy or move it later at location Y. On Windows: I have decided I want to cut XOR copy this file at location X. I can decide location Y later. I personally like the ability to chain my decisions after. Based on your edit, I guess you've already discovered, but yes on macOS, you can issue a copy command once, then duplicate it and/or move it as many times as you want, to multiple places, even if you choose a move command first. Only location X's copy is altered if doing a move. I'm not even sure if that would be possible on Windows without going back and forth between location X and Y to switch between copy and cut (my wintel machine is down at the moment).