Using : KDE-4.9.5 / Linux-3.8.13 : The problem occurs everytime.
Using : KDE-4.9.5 / Linux-3.4.43 : The problem never occurs.

Note : OK, I know KDE-4.10 is available but it is not an option for me right now.
I'd like to know if this is a known problem / Where I should start investigating.

When, under Dolphin, I copy a big file (>100M) from my home directory (ext4 fs hard disk) to a USB key (FAT fs) :
- The status notifier pops up and shows a rapidly progressing bar.
- When it reaches 0, it then hangs for 1 minute ? 2 minutes ? until some other event occurs ?
- During this time the USB device remains busy (un-unmountable / any other copy request will not start)

Note : The duration of the freeze appears significantly higher (more than twice) when running linux+BFS.

Since you run Gentoo your system is probably unique and sophisticated
What you may try is:

Copy files via cp, you can estimate time using time command.

Check if the problems exists when you use ext2 on your USB drive (both with dolphin and cp)

Check I/O waits level during copying, using top or iotop

Finally, use strace on dolphin, I'm not sure if dolphin copies files on its own or schedules copying in some system wide service. Maybe some KDE developer would help in that matter.

Wizard wrote:Since you run Gentoo your system is probably unique and sophisticated

...
Well... not that much really.

Wizard wrote:Copy files via cp, you can estimate time using time command.

I have tried, under console and under konsole a manual mount-cp-umount sequence. Everything completes in perfectly normal times.

Wizard wrote:Check I/O waits level during copying, using top or iotop

This one is strange indeed.
- I launch top in a konsole
- I then issue the copy from dolphin which completes... before I get the time to read top's output !
- I kill top
- I issue the copy from dolphin which, as usual, starts hanging... for ages...
- I then launch top from konsole => The copying [finished] notification appears before top gets the time to refresh once

Hmm... smelling a problem with inotify ?

EDIT : I cannot reproduce the last test with systematically the same results.

Hmm.. Have you tried doing "sync" when copying freezes?

Given the different kernels here - I suspect they are following different behaviour in writing changes to removable USB media. Earlier systems are probably utilising cache to speed up the transfer - while the data has not yet been written. This will work as long as the file being copied is smaller than the amount of free RAM.

On the system where you are seeing these large pauses, open htop during one of these and see if any processes have the "Blocked on I/O" status, aka. "D" showing. They will probably be "kio_file <arguments>" processes.