I read through NSSavePanel, but I don't see any access to the default panel object that gets created by runModalSavePanelForSaveOperation to get the result? I just found that my problem was caused by a recent change to my code where I wanted to know when the default save panel was done (for scripting options). I did that by using the documented selector of document:didSave:contextinfo It works in Ventura. In Somoma the selector always gets called after panel is done (for delete, cancel, or save), but it seems to prevents standard actions from happen such as closing a deleted file or even closing a file that was saved after clicking a close box. If I removed calls to that selector all is working as expected. Seems I need a new way to hear when default panel is done? It is easy for saves, but how to hear if the panel save was cancelled?

Embarrassingly, I found a solution. Instruments was indeed correct about a leak, but not much help it finding why. After looking at the same code for long time I found I had misspelled dealloc as delloc so it was never called (as the code suggested it should). After correcting the spelling, that leak (as several others too) went away. I suppose I should convert from non-ARC to ARC, but the thought if converting over 20 years of (legacy) coding, sounds like a lot of work. I might try when I retire next year.

A Solution: It appears that setNeedsDisplay has changed. My family tree is drawn in 2 passes: pass 1 calculates size of each tree cell. When that is done, tree cells (which are subviews in the main NSView) are moved to fill space by various options. Pass 2 then redraws all cells in their new proper locations. My code called setNeedsDisplay on the main NSView after subviews are repositioned. Before Sequoia, this caused the entire view to redraw, but in Sequoia, only the main view gets redrawn. All subviews remain as they were draw during pass 1. The fix was to explicitly call setNeedsDisplay for every subview as well. I see setNeedsDisplay is deprecated, but it seems to have changed now too. I still see subview cells drawing in reverse order compared to prior MacOS versions. Because I move cells to avoid overlap, it is not a problem in my window. It seems like that change would affect any application where subviews might overlap (and therefore drawing order would matter).