I agree to that. It's bad usability-wise. I am adding my votes here but I think this should be a wish, not a bug.

Konqueror (KIO) emulates cp -a rather cp on purpose, most users don't know "cp" and rather just want to make a copy of what they see (a link, or a directory, etc.) (and preserving mtime etc. makes sense too).

However I agree that offering "copy source file" (or something like that) in the popup menu that appears when dropping a file could be useful, when the source URL is a (single) symlink. This would only make it available when using drag-n-drop though, not when using copy/paste.

Another option in the popup with something like "copy source" would be really fine, but why should that be valid only for one file? Originally I had a directory with many symlinks only and even if there are files directories and symlinks why should the "copy source" option not be shown in this case? I cannot see the logic behind this restriction, it would be inconistant, introducing a special mode in the interface without a special need to do so?  At least I would wonder why if I would select one symlink and could see the option but if I selected 2 symlinks I would not see this option. This would be what I called inconsistant.

I think such an option would only be useful if you can choose it whenever you copy files (except for copy/paste) no matter if you selected a single file or several files, symlinks and directories. The meaning would always be: If there is a symbolic link somewhere in the files to be copied we will copy the file it points to not the link itself. This is clear and consistant. 

It can be done for "two symlinks", of course, but not for the case where you drop a directory. 
Because we don't know what's inside the directory yet, we would have to always show the option,
and that option would be very confusing then ("copy source? sure, what else?").
It could be named "copy (follow symlinks)", but again I wouldn't want to expose all users to these
terms if they are copying a directory without symlinks in them... A difficult problem.
Maybe a config option in the configuration dialog would be better, then the day-to-day interface
would remain the same. But this assumes people don't often want to switch that behavior.

I see. 
My motivation is if you think of copying a directory tree to a flash card with fat filesystem (eg mp3 files or photos etc) then it really is important to have this option for a whole directory tree. fat does not know about  symlinks and so the regular copy with konqueror fails as soon as there is a symlink. Devices with FAT filesystem are very common today. With a new option "follow symlink" it would work. But of course I do not always know if there is a symlink inside the source but I know if there is one I would like to copy the file it points to. 

So I would vote for your proposal for an option that lets the user decide if he wants to see the "follow symlink" option in the copy popup. The day by day user would go on to see what he is used to but if he really wants/needs this feature he could switch it on and from then on it would appear in the popup and enable the user to do a "follow symlink" copy.  

I do not think that such a user wants to turn it off and on again very often, at least I wouldn't. Its a personal setting and I know why I turned it on and what it does, so why deactivate/activate it often? I would simply leave it activated. 

Good point about copying to FAT systems (and to removable devices).
This is something we could detect automatically, removing the need for a configuration option.

An automatic detection would have to detect all filesystems of removable devices that do not allow symbolic links and copy files accordingly. Not each removeable device (eg a usb-disk) will always have a FAT filesystem so the automatic recognition would really need to analyse the fs on the device.

The advantage of this solution is that it would work, say in 90% I guess. The disadvantage is that the user has no control when or where symlinks are resolved and copied to files. If you for example copy a directory tree to an external usb-harddisk with say an ext3 filesystem on it, you probably do not want to keep the symlinks, which might point to nowhere if you attach this portable disk to another system.  So I vote to let the user choose because he (should) know what he wants to do.

So perhaps a mix of automatic detection for devices with FAT fs on them (which requires a follow symlink copy)  as well as an additional setup option (off by default) that allows the user to have explicit control on how symlinks are processed for each copy operation he performs. I think this would be optimal.

Allow me to present a use case to motivate potential coders :-)

Teachers reuse a lot of their materials from one year to the next. So I have all my lessons in big categories like "beginners" and "advanced". Since I must adapt to my students abilities, the lessons are almost never in the same order or learned at the same speed (meaning I may add more exercises as the year goes on). So each year I create a new folder named after the school year (e.g. "2008-2009") to keep a log of what was done and in what order.

This is how i create a lesson plan:
- copy the files from one of the categories to the school year folder,
- add a number to filenames to order my lessons (KRename is great for that),
- copy the needed files to my USB drive before giving a class.

As you can imagine, this process consumes a lot of space. I have been doing that for only 3 years and I already have 5 Gb worth of copies.

In theory the ability to symlink lessons is great but conflicts with my need to carry the lessons on a USB drive.

So please l33t coders, allow us to copy the source files when moving symbolic links.