In actuality, the release itself was about a week ago (03Aug2022), but circumstances prevented the timely release of this notice at that time. Nevertheless it is out, and is primarily a defect repair release, at least as viewed from a User point-of-view. Fixes include a misnamed variable reference that led to illogical 'blanks-suppression' displays during inline highlighting; revising code to avoid a race condition during the construction of the main display; repaired uniqueness of menu accelerators, and a loosening of restrictions for the POPUP Menu regarding where it can be invoked (now works over scrollbars/labels PROVIDED they have a Left/Right connotation.
In terms of NEW abilities, the changes are fairly subtle: The most visible is a new display within the status bar that provides a readout on how the "merges" are distributed relative to their Left or Right nature, which serves two purposes. One is that you can readily identify which side is contributing the majority (and hence agrees - or not - with the INTENT of the merge overall); but it also serves as a reminder of how much work may have ALREADY been done in selecting merge choices - and thus how much could be LOST should you cause a NEW Diff operation to become triggered. To further enhance this WARNING aspect, the user actions that can CAUSE such an inadvertent "Diff" to occur, will now precipitate a warning highlight to occur FIRST, allowing the user to think twice before finalizing the action. Of lesser concern to the average user, there is also a new category of Preferences, that deals with HOW TkDiff integrates and interfaces to the underlying Diff tool it relies on. This new means of integration gives rise to the possibility of using a "work-alike" tool, should there be a viable replacement that might better suit the needs of the text being Diff'ed. The updated Help information contains further details on an example of such a reconfiguration, should this be of interest. Note however, that because of this "formalization" of the TkDiff/Diff boundary, it is advisable to at least review how any PRIOR Preference values become "converted" to operate within this new release. There is a distinct chance of excess DUPLICATED values that should be pared BACK to avoid any confusion (particularly concerning the exclusion of files to be Diff'ed when searching for candidates).