Hi calmh,
Thanx for the feedback.
I am not sure about the CPU issue. Somehow, the behavior on that seems to be inconsistent. So, I am not sure how much you can rely on it. I tried to go back to beta3 as I initially thought that that one was not eating the CPU, but then, after some hours it seems to have started doing that as well. Unfortunately, I do not like to let it run overheated for a long time, so, after a few minutes I decided to exit. I am not sure what I am seeing here because nothing seems to be going on.
Then I tried to go back to 0.8.21 and it seems to be better in term of CPU load.
As far as configs go, I did not change anything when going back to .8.21. So, I’m not sure if I have a problem that I don’t know exists. If you think there IS a problem, would be great if you tell me what exactly do I have to change in configs. I don’t even know where they are 
Side issue - Logging:
If you recall, I suggested to add some more detailed logging as to dynamic nature of things. Sorry, I did not follow up on that post because I am swamped with extremely important things to be done. Hope you can understand.
I am not sure what makes sense to YOU, but what I did in my last project is to provide logging of different operations. The program I worked on had to do with NNTP functionality. So, there are operations, like downloading or posting. During those operations, you have different things happening, like connecting to server, loading configs, processing archives, actual downloading or posting, etc. And you also have some intermediate results or statuses of completion, error, not critical warnings which mean the system had to take some default value as a result of some wrong or incomplete information provided in the configuration, etc.
So, each module that does some major operation has a status line and history log box in GUI. Status line displays the current thing being done, like connecting, loading, etc., and a rate of success. It is also automatically copied to a scrolling history box in the module’s GUI and also to the main program window. The same history box, but not all the details are displayed there. That one is only for major things program-wise.
The logging process is completely automatic and daily logs are automatically created upon program start as rotating logs, such as log_YYMMDD.txt, which is a regular text file.
So, what happens is no matter what the issue is or where you are in execution process, you have date/time stamped log messages in the log file that tell you which operation is in progress, which exact archive is being loaded, and was it loaded successfully, which exact message is being posted and so on.
As a result, I was able to find some pretty nasty bugs within minutes because logging is pretty descriptive.
In your case, what I see is that you could log different major phases of operation that, for example, tell you that you are trying to connect and upload to remote node such and such and are trying to sync such and such a share. On a more detailed level, you might want to say something like: “YYMMDD HHMMSS: Uploading file such and such”. Once it is done, you display “… completed”. Else, you display … error: detailed reason for error and which incorrect parameter or file or something else caused which exact incorrect behavior and what was expected to happen. Like “>>> ERROR: could not write to file filename,” or “>>> ERROR: file does not exist”, or “>>> ERROR: expected parameter this, but it is all claborred…” and things like that.
Also, any intermediary and possibly minor errors or warnings could be logged with time stamps.
You could have several different logs. One is for major system status things. Like starting to run, loading configs, starting upload and so on. You may not want to provide too much details in that log and use a separate log for file transfers and related status messages.
So, what you have is a system where behavior on different levels and from different aspects is logged in a detailed manner and anyone could simply open that log in his Notepad++ editor and have it automatically updated by syncthing in case there is something funky going on.
Otherwise, I am having a hard time to comprehend what is actually going on in terms of system dynamics. Where is the system right now, is it idling, is it doing some maintenance work, checking something, verifying integrity of something, which files is it transferring right now, which way, from where to where, what is the progress of transfer, what is the percentage of the total file size that have been transferred and so on.
In other words, I’d LOVE to see the system dynamics. Not sure if some of it could go to a GUI into some scroll box and which part would not be desirable to see in the GUI. But I like those scroll boxes with more or less complete logs on each module’s window.
So… How much of it makes sense to you, only you know. If you’d like some clarification, I’d be willing to spend some time on it.
Good luck. I like the program and I do like the GUI. Nice large text and those colored fields and buttons, structured so the display is not cluttered with too much information and things like that. I just wish it would be more informative as to dynamics of things.
Another thing - I’d LOVE to see that issue with automatic public shares joining the appropriate swarm without any user interaction resolved, just the way it is done on BTSync, for example. Basically, it looks to me that if you add a concept of a public SHARE KEY, not just node ID, then you should be able to automatically join those shares without even showing the rest of the shares on remote nodes. It looks like a parallel mechanism. But I am not sure about the desirability of requirement for any user interaction to join some share for PUBLIC shares that should be made available to any node regardless. So, the user could join either the way it is done right now, or by share key, in which case different logic applies. If someone is joining by share key, ALL they see on any node is that share only. You might even decide to have a tab in GUI that displays things differently for public, by share, nodes and regular nodes. So, on share GUI page all you see is the list of nodes currently sitting on that share and you may not even have any idea that the system behaves totally differently if it is accessed by the node ID key and what is displayed to them. On that page you may decide to implement the hold or drop functionality, just like it is done on uTorrent for example where you can put some torrent on hold or stop it completely without deleting it as such.
Yes, you could add the “accept” node functionality, or even exclude some node from some share. But this stuff gets hairy in a hurry and I am really way too busy with things I do to have a good look at syncthing in terms of code. Plus I do not know GO even though from a quick look it reminded me Pascal.
Why did you chose GO, if you don’t mind the question? Is there something special about it that could be described in a sentence or two?
Anyway, I do appreciate your work and the project seems to be going in the right direction and I’ve been using the program for about a month now and so far, it is quite reasonable and well behaved. Sure, there are all sorts of things to be done, like with anything else, but the idea is right as far as I can see without diving into it upto my ears.
Good luck and thanks again for all the work you are tirelessly doing and keeping the project going.
The notes below still apply, with the following additions:
Don’t deploy this in production or on valuable data! 
The “latest release” link also points to the latest v0.8 release, not to a beta. And there’s this thing with the red exclamation marks and “do not run in production” above…