To sneak in some extra information on this while I'm sitting at my desk, watching some very slow automated tasks in my day job:
Re: the stencil; this is used because the CRT is its own sealed component trying to act like a real CRT. So it's attempting to sync to any incoming signal, and it paints scans to a virtual set of phosphors, which subsequently suffer exponential decay. It actually does this in a matter decoupled from your machine's frame rate for the reason that if you have a gaming monitor at 120Hz or 144Hz it can then provide 120 or 144 distinct frames per second, just like a real-life CRT doesn't atomically flip from one frame to the next, and you gain a big graphical latency reduction. The stencil is related to the exponential decay — that's just a discrete in-framebuffer effect, as you'd probably guess, but given that machines may not produce regular sync, which may cause the number of pixels painted sometimes not to reach the edges of the display, an extra means is needed to keep track of which pixels haven't been repainted by the normal scan.
A ColecoVision produces an entirely stable display, so it's not actually much help here, other than possibly for clearing up after the bouncing that happens during initial switch on. It is nevertheless essential to allow the virtual CRT to fulfill its stated contract, and in practice a big help to other machines the emulator implements.
Re: 'revert to saved'; the Mac version is, as stated, a full native application. Specifically it's an NSDocument/NSDocumentController-type application with XIBs aplenty, utilising an NSOpenGLView, CVDisplayLink, CoreAudio and IOKit for joypads and so on. That's nice because I get all the window management and most of the default menu bar items and their implementations for free. But it means I have to respond properly to the NSDocument messages. So every so often it turns out there's a menu option that isn't working because I'm not responding to a message like I should. It's just usually not immediately obvious what I've done wrong because I'm relatively weak at AppKit. It's not like I've tried to add a 'revert to saved' feature and failed to test it, I've actually been entirely oblivious to the menu entry.
The SDL port, which allows use under Linux and similar environments, is completely distinct. Not one jot of SDL is used on the Mac.
I have every intention of switching to Metal given that OpenGL is now deprecated on the Mac, and as of this overhaul the use of OpenGL by a particular binding is entirely optional. In practice it can be specified at runtime, which gives me a fallback for non-Metal Macs. It's just unfortunate that I don't presently know that much about Metal right now.
Tech nerd asides: if you've any experience of pootling around in emulation source code, you might now be imagining a viper's nest of #ifdefs and equivalent runtime selection mechanisms, and a project that will surely die quickly under its own weight. There's none of that. The machine owner supplies the delegates to receive audio and video content, and pushes changes in input controls, and that's the end of that. I keep angling towards a Windows or Android port and, if ever I go that way, that will mean extra code to handle DirectX and/or OpenGL ES, but will require zero lines difference within the emulation. It'll just be a new consumer, or two, of the information the emulation puts out.