Sometimes, the diff panels on each file in semanticdiff are too narrow, even when hiding the Semantic Outline. Allowing horizontal scrolling with Shift + Mouse wheel would help reviewing long lines of code. A word wrap option would also do the job, although having both would be the best.

Semantic Merge allows for external parsers but currently it only allows for one, making the adoption of using them very limited, when you are using more than one non-supported language. I would like it if Semantic Merge could support configuring external parsers by extensions they handle.

how awesome would it be if you join forces with another tool vendor and create a full integration of your semantic diff (including moving things from one file to another) and a tool that helps during code reviews and tracks findings...
finally one could focus on real changes

Currently, during a 3-way merge, the individual differences are marked only on the Remote, Base and Local files.

On the Result file, it is only shown the main change (line deleted or added), the individual changes are not shown. For example, if you rename a word in one line, on the 3 source files you have that work highlighted, however, on the result file, it's not highlighted, which makes it hard to see what the difference was.

This would be very useful when solving merge conflicts, because then we could see the differences clearly with the changes on top of each other.

Currently, during a 3-way merge, the individual differences are marked only on the Remote, Base and Local files.

On the Result file, it is only shown the main change (line deleted or added), the individual changes are not shown. For example, if you rename a word in one line, on the 3 source files you have that work highlighted, however, on the result file, it's not highlighted, which makes it hard to see what the difference was.

This would be very useful when solving merge conflicts, because then we could see the differences clearly with the changes on top of…

Currently, during a 3-way merge, the shown differences are always between Remote/Base and Local/Base.

It would be great to have the possibility of also showing the differences between Remote/Local.

Why? Sometimes the Remote and Local files are exactly the same and since the differences are marked on them when compared to Base they seem to be very different to each other. We have then to open or copy/paste both Remote and Local files on a file editor and then compare them, to see that they are exactly the same.

This is quite common, because when we use squash in Git we end up with branches very similar but with quite old base files...

Currently, during a 3-way merge, the shown differences are always between Remote/Base and Local/Base.

It would be great to have the possibility of also showing the differences between Remote/Local.

Why? Sometimes the Remote and Local files are exactly the same and since the differences are marked on them when compared to Base they seem to be very different to each other. We have then to open or copy/paste both Remote and Local files on a file editor and then compare them, to see that they are exactly the same.

Beyond Compare has a feature that I love: you can tell it which string (typically a variable name) on the left side correspond to which string on the right side. For example, you could tell that a variable "dollar" was renamed to "currency" and SM would change all instances automatically.
Even better if, when a rename is detected, you can "approve" all renames in that particular scope.

I think that the comments should be treated as a separate category of changes. That is, we have sections for Added, Removed, Moved, Changed. I would think it useful to have a Changed Comments. This is worthwhile because comment changes are much less important than code changes. If I do a lot of documentation changes, and in the same commit I happened to make a small code change (intentionally or not), I want that code change to stand out. The documentation is not nearly as important as the code itself.

Currently, the #region and #endregion tags are treated as part of the comments for the method that occurs after them. As such, if you organize your code with these #region sections, and then you happen to move a method just below a #region to a different place, and then you have a merge conflict over that method, then the regions get messed up.