This is a really clean approach. I've been doing something similar for my CL game engine, but I hit a few gotchas worth mentioning:

The Wine overhead for the REPL is surprisingly minimal - maybe 50-100MB extra RAM and no noticeable latency. The real pain point is when you need Windows-specific debugging. Wine's implementation of Windows debugging APIs is... spotty. If you hit a nasty FFI crash, you're basically flying blind compared to native development.

For the DLL loading, one trick I learned: use GetProcAddress equivalents through CFFI instead of relying on load-time symbol resolution. This lets you gracefully handle missing functions between different Windows versions without crashing on startup. Particularly useful if you're targeting both Windows 7 holdouts and Windows 11.

Also worth noting: if you're distributing commercially, the mingw runtime has some licensing quirks. The "posix" threading model links against winpthread which is GPL (with exceptions), while the "win32" model avoids this but lacks some C++11 features. For pure C code it's usually fine, but check your dependencies.

The 40MB executable size is brutal though. I ended up using UPX on the Windows builds which gets it down to ~12MB with decent decompression speed. Just add upx --best aero-fighter.exe to your build script. Some antivirus software gets twitchy about UPX-compressed executables, but it's generally fine for games.

Anyone know if SBCL's Windows fork has plans to add core compression? Seems like low-hanging fruit given how well it works on other platforms.