I could give you so many, but I'll kick off with just three that spring to mind. i] Keyboard navigation is terrible. ii] Tags cannot be applied to symlinks. iii] If you're looking at a tree view, with any number of folders displaying, the only one you can create a new folder inside is the very top-level folder.
My biggest complaint: Normal Copy and Paste does not work. My mother is used to Copy and Paste and it would work in Linux but not in macOS finder because of: think different
Also why are folders sometimes cluttered all over the place and shorts cuts so weird?
Well I fixed it all with Forklift but I also grew up with Norton Commander ;)
What about copy and paste doesn't work...? I use that feature daily.
And for the clutter, you can configure Finder to be more militant in how it displays/orders things.
The only gripe I have with Finder is needing to set up a million QLPreview things to do better spacebar peeking. Otherwise, it's fine - it "just works" and isn't fancy.
I think they possibly mis-spoke and mean cut-and-paste, which does appear to be intentionally permanently disabled in Finder via the menu or shortcut. But you can drag so it's not a huge issue to me. Copy-and-paste works a-ok.
That's not cut-and-paste. That's copy and some weird modified paste that, as far as I'm aware, doesn't exist anywhere else. Why completely break the existing convention?
Because cutting-and-pasting is a destructive action that can lead to data loss.
Under the conventional implementation of cut-and-paste, it's easy for a user to inadvertently cut-and-paste a file, when they meant to copy-and-paste said file, either through a misclick or, by hitting the wrong keyboard combination. This is because:
1. The menu option for cut is right above the menu option for copy
2. The keyboard shortcut for cut (command-c) is just one key away from the keyboard shortcut for copy (command-c) on a QWERTY keyboard
Cutting and pasting deletes the file from its original directory, however under a traditional cut-and-paste operation, the system does not ask for confirmation. Consequently, if a user mistakenly cuts a file or directory without immediately noticing their mistake, their files could be rendered unrecoverable (and keep in mind that there's no particular reason why they would notice... the UI provides no special indication when a file or directory is deleted via cut-and-paste). This is arguably a very bad user experience.
The equivalent action to cutting-and-pasting on OS X is copying, pasting and then deleting the original file. By adding in this extra step, the UI has forced users to acknowledge that their action is potentially destructive and unrecoverable.
Also notice that the command-x shortcut in Finder copies a file. It does not cut the file. Again, this protects the user from inadvertent data loss if they use the wrong keyboard shortcut.
It's a rather unusual move Apple has made here by breaking convention, but I think they've made a wise wager that users would rather be annoyed by a small extra step, then be faced with the loss of important data.
Thinking about this design choice, I now wonder how many times I've had files mysteriously go missing on Windows and other operating systems simply because I used CTRL+X when I meant to use CTRL+C
Symlinks on the desktop or in Finder to files on network mounts don't receive preview thumbnails. But if you drag that same directory to the dock, those symlinks do receive thumbnails (but only when viewed through the dock.)