Awesome, good idea to change the title. Yes, I believe you got it right.  I hope it still conveys the idea that the checkout and fast-forward merge operations to be done as a single "step" (from the files standpoint at least) else it's pretty much pointless other than saving a few mouse clicks.

I just discovered that I could run the custom tool "ff-merge.sh" from the context menu and it appear to achieve roughly what I want just not great UX there. I can run this tool and no changes are performed on the working directory until I do a separate checkout 'develop'.

Integrating this special fast-forward merge for a more powerful checkout is where a tool like SmartGit can shine: Higher-level operations made easier, no need to know in advance that this is actually called a "fast forward merge". (not feeling like you are merging anything here).

I am not sure what you mean, but in the attached picture, SmartGit says "Local branch 'develop' is diverged from checkout target 'origin/develop' -- this does not seem to match what you are talking. (correct me if I am wrong). There are no commits on local develop. In this case, a git pull on 'develop' would immediately jump to 'origin/develop'.  

- If you mean uncommitted changes, then yes, in that case it might not be good. Although I don't know why we couldn't simply go into the standard Stash/Apply dance.
- If you mean a local commit on 'develop' that has not been pushed to 'origin', then I understand you would need a re-base of some sort or it's gone. I believe we can detect this case and simply not allow to perform this "direct" operation.

In the picture, I right-clicked the "origin/develop" yellow branch and did "Checkout". You can see I was on another branch. I think SmartGit can easily detect if it is safe and perform a checkout without loosing anything. I certainly do not want to create a local branch "develop-2".  

I also understand that there could be multiple local branches tracking the selected target, well, this is why you would have a branch selector similar to the one that is already present but only showing branches that are tracking the target.

I am not a git command line wiz, but I suspect it might not be obvious to implement this without being absolutely certain that there is no possibility of loosing something because maybe the origin diverged wildly differently while the operation is executing.

Atlassian SourceTree does something similar and I must confess that it throws me off. The "rounded dots" are commits (even if you change their color).  So if we do this, then you should use a completely different icon (like you see for Stashes for example). It must be 100% clear to the user these are not "commits". (and if I do not want to see them, you can hide them).  
True that it would also give a way to quickly see the uncommitted files without hunting for the main window in your desktop.

Oh wow! I didn't realize what it was (or I never saw it). Yes, this looks like exactly what I needed. Awesome!  I do not want to hijack this "Idea" thread too much as it is clearly OT now, but anyways, I guess my thing boils doing to a UX issue (i.e. discoverability of the feature). Hum, maybe add a button on the toolbar to jump to the Base (and maybe one in the base to open the Merge window)?  And even better: display some stats about the Merge Diffs i.e. "+14 -400" and include the Base Diffs numbers too so at a glance we can see where the "meat" is coming from. Maybe even have more clever numbers that would help determine how "simple" is a change (number of characters? % repeated character change? Anyways, call me crazy)

I agree with Marc, a toggle button is not very good UX.
If what you want is to save space, another option is to remove the "text" under the buttons and/or remove all the buttons you never use. I personally only use 7 buttons out of the 18 I am seeing as of this writing. (well, that's because I use the context menu a lot).

This is maybe unrelated, but the tools might be somewhat similar or at least you might bake a solution that could satisfy both cases.

What would be extremely helpful in the Conflict Solver is to know what was the change that occurred on a side alone. This is something you do not see from the Conflict Solver window (correct me if I am wrong). This is extremely useful because often the changes from one of the side is very simple (like a name change) yet it yields lots of conflict.  If there could be a way to see the change that happened on one side that we are trying to merge to help understand what's going on. 

Let me try to explain differently:

If you are the creator of that simple change and it was recent, then you can "remember" what it was and you can proceed doing the merge easily. (essentially re-doing the simple change over the new code, like a repetitive change spread all over the file). But if you have no idea what was the original simple change, then it is not always obvious to understand what's going on. When I suspect I might be in that situation, I go back in history on both sides to see what are the changes alone to understand. It takes time and is not always obvious on how to go about doing that in SmartGit/DeepGit. If we could temporarily see the changes from one side easily this would be by far the best conflict solver I've ever seen.  

I think the changes of a "side" would be showing the diff of that file between the version before the current merge up to the "common" commit. (i.e. what we are trying to merge essentially).

If you need more information on this topic, I might be able to provide a better thorough example.

Sounds like what you want is having the Log functionality directly within the main window. (instead of the other way around)?  There is already a concise log (Journal) which provides partial Log Window functionality. Maybe this could be improved to fit what you are trying to achieve.