I think this is pretty clear -- sorting is just another way of reordering items in a list.  However once I get around to implementing undo (which is already reported) it might make sense to allow undoing of the sort order.  But of course if you want different sort orders you can either save it before reordering or use "Duplicate" to create an identical set of items and order them differently.

A playlist, to me, is an ordered set of songs.  While you're right, sorting is only another way of reordoring that set, the order of a playlist in particular cannot be recovered once that operation is done.  Sorting effectively destroys the order.  

Why is this a problem?  Because the list view that's used in juk is used to view data in different ways, not to change it.  It makes a lot of sense for applications in which the order is unimportant or where the order is captured in one of the columns.  KMail, for example, has a Date column which represents the primary order of messages.  A directory is an unordered set of files, so it makes sense for konqueror to arbitrarily manipulate file order when viewing a directory.  It makes sense when browsing songs in the "Collection List" in juk, since any relevant order information is usually captured in the "Track Number" field.  

I don't think undo functionality is appropriate in this case because the sort columns should not have "operation" semantics.  XMMS is a case where it does makes sense, since its sorting functionality is driven by a command from a menu. 

Try making a playlist that you intend to burn to cd - I think you'll see what I mean.

(More along the same lines: can a search playlist be reordered?  I think it shouldn't be, because it's dynamic subset of an already unordered set.  Whenever it changes, its unclear what to do with the order.) 

I agree with the originator that this should be resolved. Why not have a column for the order that files were queued? That seems an appropriate solution that allows things to be easily resorted/reordered.