Of course you'll still need to unmount, just as you are meant to do on windows (at least if it's a mass storage device). In most modern file managers you just need to right click the drive icon in the list of mount points towards the left somewhere to bring up the menu containing the unmount option.
Yes, I get/understand/grok unmounting the media prior to removal. I'm just annoyed that my Linux box can sit unused & idle for 20 minutes after a file copy, then when I tell it to umount the usb, that is when it -starts- writing and proceeds to happily spool data off to the USB for the next 1 to 100+ minutes with no indication of how long this is going to take.
The user shouldn't have to guess how much data is pending to be written to a removable device. The GUI file managers on most Linux DE environments show file copy progress in a separate window and you can merrily go about adding items to that queue. From the file manager's perspective, though, when data has been read and written to the OS pipe for the target, the task is 'done'.
Writes to removable devices on non-server platforms should be an immediate and high priority process - keep that write buffer full until done. If write caching is going to be ubiquitous, then there needs to be something at the UI level showing pending writes and estimated time to completion for every cached device. Preferably this should be shown on the distribution's DEs included file management GUI.
If you're working from a remote command line, cached writes mean you can use the same prompt and keep doing stuff while the OS sorts out the rest - great. If you're working from a local GUI doing normal desktop user tasks, though, not so great.
Pyra use case example:
Two people (Jack & Jill) take pictures using real cameras with SD cards at a wedding and want to directly share/swap photos.
Jack's SD card goes in the left slot.
Jill's SD card goes in the right slot.
Using the file manager on the UI, Jill (it is her Pyra) rubber bands Jack's photos, right clicks copy, goes to her card, creates a Jack directory, opens it, then right clicks paste into it. A dialog box pops up talking about the process. She then goes up a directory on her card, rubber bands everything but the Jack directory, right clicks copy, goes to Jack's card, creates a Jill directory, opens it then right clicks paste into it.
Five minutes later the Pyra's FM says it is done.
Jill tells the card to eject/unmount.
The writes then start to both cards, drive lights flash like mad again, and the Pyra appears 'locked up'.
If Jill is a Linux power user she knows that the device is flushing the cache and doing the actual work that she had asked it to do.
If Jill is a normal human, she's confused, annoyed and suspects that the Pyra is eating all of her wedding photos.
Worst case scenario she panics, ejects the half-written SD media (possibly bricking the cards) or hard power cycles the Pyra (possibly bricking the cards).