Fixed in 2eb3740b0 (the two DiagramDesignerFrmUnit hunks landed earlier in d6f5c6fc).

The popup header and the OTFT editor computed 'how many OFTypes am I editing' two different ways. The diagram counted drawn TDOTFT elements and ignored the MultiEdit preference; EditOTFT resolved every selected element through OFTypes.SearchName - roles, constraints and shapes resolve to nothing - and did honour the preference. So the header could announce a merge the dialog never delivered.

SelectionEditCount / CollectSelectedOtfts in OtftEditorDlgUnit are now the single answer for both. They resolve an IItemList selection into the distinct OFTypes an edit would really open: non-OFType elements are skipped, duplicates dropped, the count capped at 1 when the preference is off, and index 0 is still probed when SelCount = 0 so the diagram's FocusOn fallback survives.

Four defects fixed underneath:

• the diagram popup routed through MainDmd.EditOtftAct, which acts on FormManager.ActiveItem (derived from Screen.ActiveControl). With the Expression Viewer focused, the diagram's own popup edited the Expression Viewer's single selection. New TDrawingMenuDmd.EditSelectionInDrawing calls the owning diagram's ISelectionEdit instead, and the menu item's enabling follows the same source.
• TDiagramDesignerFrm.SelectionEdit skipped the multi path whenever any role sat in the selection, dropping the OTFT edit entirely instead of merging.
• EditOTFT(ISelectionEdit) raised a list index error on MergeRecords[0] when nothing in the selection resolved, and leaked the merge record when it did not merge; EditOTFT(AMG, aOtft) returned an uninitialised Result for nil.
• TDiagramDesignerFrm.GetSelectedObject used 'index in [0, RoleSelectedList.Count - 1]', a two-element set rather than a range, so every role between the first and the last answered nil.

The Expression Viewer already had a merge path but counted selected rows rather than resolvable OFTypes and merged unconditionally; with the focus in the expressions list that meant nothing opened. It now uses the shared count and falls back to the focused OTFT when the count is 1.

Full rebuild of CaseTalk.dproj (BetaEdition) is clean. Not verified against a running model - worth a check that the diagram case behaves; if it still misbehaves, which pane had focus at right-click distinguishes the routing cause from the counting one.