I just thought it might be worthwhile posting my first impressions while using the encoder in the PHPed environment. A few ideas jumped out at me (I guess it's an occupational hazard of coding apps for coders - we're constantly looking for fixes).

I saw a suggestion to delete all old files before doing an 'encode project'. I thought it might be better to just encode the file to an intermediate location, and compare the compiled with the existing. If they are different then overwrite, otherwise discard. This may seem like a waste of time, but I'm using an scp synchronizing tool, and if they are all rewritten, they are all re-uploaded. This would solve it.

This assumes that encoded files always encode the same (and I guess they might not).

Actually ... dumb question time ... is there an upload tool in PHPed that supports a secure FTP variant. Will have a hunt around for that.

Next, there is an option to suppress all success messages. I think that there should either be an additional option to suppress 'copied' messages, or the success messages suppression should include copies.

Also, when problems appear in the log, you can double click to see the file. Thats good, but if there is more than one problem on a page (I had a bunch of creating objects by reference errors) if you click on each of them, the file gets opened twice and when you correct one, you get a reload warning on the other. So basically, you have to either open the file, save, close and then click the next problem, find the second problam maunally, or just make sure the fixes star fixed despite reloads. Just annoying is all. My suggestion here is simply to check if the file is already open and to just relocate the cursor to the problem line.

Nothing too major ... just little fiddly stuff.

Other than that, great work guys.

Sure but it would require a serious extra amount of logic to implement (and it probably is a lot slower too due to the comparing per file).
Easier would be if the encoder just copied the files' modification/creation time and attributes (as I requested already) etc onto the encoded file. That way the target folder could still be emptied, ridding it of files that could be obsolete in the source project right now. Those extra files would still be there with your suggestion. But I surely like the idea behind it!

As for the rest, agreed

Yes, of course. See Tools->Accounts->New->SFTP

Then you may want to use Smart Upload to have local file date/time stamp and/or size to be compared with remote ones.
Also you can ENCODE FILES ON THE FLY, while uploading.