An example is.
ioSetCursorARGB in interp.c calls the C interface ioSetCursorARGB in sqSqueakCursorAPI.m where there is a call to execute the Obj-C methods in sqSqueakOSXApplication+cursor.m, the ioSetCursorARGB contain a autorelease pool wrapper.
However this is fine grained as the sqSqueakOSXApplication+cursor.m code could change and introduce a autorelease object before the guard clauses, etc.
This is what happened in pumpRunLoopEventSendAndSignal where there was no autorelease pool because the code didn't require it, but over the years a code change introduced the autorelease object leak.
So a safer choice would be to wrap ioSetCursorARGB in sqSqueakCursorAPI.m to ensure mistakes don't happen as the actual implementation code is changed.
In general I originally wrote the code to call from interp.c to an exposed C routine, to the obj-c logic, so I am hoping this change will be 'simple'.
There is more of an issue for plugins, as they are of course C routines, but could call Obj-C. For those it might just fall back to the authors to ensure they don't leak.