Copy Queue=none
doesn't work as supposed for FTP sites. It adds copy task to standard queue instead of copying immediately. I guess it's a bug rather than intentional behavior.
I can't reproduce this, it works ok when I try it.
Now, when I try to test with button
copy queue=none
error occurs.
The button works ok when there are no active transfers. But when there's one file being copied to the FTP site and I try this button again (on another file), it results in this error.
Unfortunately I don't know how to obtain error message in english.
Maybe the FTP site can't transfer more than one file at once.
Check the FTP log.
Today copying two files simultaneously works ok. 
Nevertheless, still problem with queue=none
If I use a button with copy queue=none it works ok and files are not queued.
But if I drag and drop files holding Alt, they are always added to the queue.
Drag-and-drop + Alt command for all files and folders:
copy QUEUE=none FLATVIEWCOPY=single MOVEWHENSAME
Drag & drop to FTP sites does not run the actual commands in the drop event; it just inspects them to work out if the operation should be a copy (results in a standard copy being performed), a move (standard move) or something else (the drop is blocked).
You'd have to disable automatic queueing to prevent a drag & drop to FTP from being queued.
Yeah, I could see several times that ftp sites don't behave the same way normal folders do.
Eg. I can't set an FTP or FTP folder as tree root, also most context menus don't work for FTP sites, this is why I also can't set a drop menu entry (no queue) for ftp sites.
Did you plan anything to change it so using FTP folder is more like using local one?
Most commands don't work with FTP, since it's unlike a real filesystem, hence it being treated differently.