Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Oddly, drop cursed works to drop all cursed items, but drop magic does not.
Kevin R. Bulgrien
Cursed things are in a sense always cursed (marked red), when they are identified or not and it certainly makes sense that there is more good reason to drop them than magical items. Though the reason for dropping magical items is less important, there is still a reason to want to drop them all (sorting loot). Though there is a subtle difference in that the color marking and (magic) identifier is removed when identified, the client does have a way of knowing magic items since it can sort magical icons to one of the inventory tabs. Even if all magical items, identified or not, are handled by a drop magic seems to make sense. One can always lock things one does not want to drop.
Changing to a server issue. I doubt the client has anything to do with the implementation of drop in this sense.
Detecting if an object is magical or not is currently non-trivial if the object in question is also identified. See is_magical() in common/item.c. Some quick testing indicate that the FLAG_KNOWN_MAGICAL is unset on identification (at least of rods, which was what I tried it on).
To avoid recalculating all the time (which is, relatively speaking, rather time consuming), a new flag would have to be added to the obj structure (or to the obj->flags field, if there is any place left there still). Or the FLAG_KNOWN_MAGICAL must be kept even after objects are identified, and several parts of the code updated to handle this.
I'm not sure if it would be required to update archetypes, maps, and player files too, but it is quite possible that would be the case. If the meaning of FLAG_KNOWN_MAGICAL is not changed, it would probably also require a new is_magic or similar line to be added to the file format.