SDL 1.2 is a problem that won't go away.
Although we accept patches in revision control, we aren't ever doing another formal release of it, and it hasn't been seriously maintained in years. 1.2.15, the final release, was born 11 days before my daughter, who's now halfway through 1st grade.
Most of the things you love are using SDL2 at this point, but there are notable exceptions, not to mention legacy things that will never be updated, and often on legacy apps, the most intense piece of bitrot is SDL 1.2.
This is a good thing, in a way, as SDL was intended to be swapped out with better builds as new tech rolled in, isolating the game itself from platform and API incompatibilities. Better to have an open source shared library be the point of failure, instead of a binary blob from a company that folded decades ago.
When we started seriously focusing on SDL2, we made a conscious choice to abandon 1.2. It didn't make sense to maintain two separate APIs that sorta smelled the same, and the internals had changed enough that implementing an audio or video target for one library would be a complete rewrite for the other. If nothing else, we wanted to encourage people to move to the thing we moved to, since we had spent so long fixing interface mistakes of the past in the new version.
In recent years, however, those that remain on 1.2 are feeling the pain. Even if they don't care about new cool features in SDL2, they're left out of new platforms, new targets like Wayland video and WASAPI audio, and if nothing else: bug fixes. Things fall apart, and if you're stuck on 1.2, that's been your problem.
Recently I started back up on an ancient project I never got too far with before, called sdl12-compat. The idea is to provide a binary that looks like SDL 1.2 to the legacy app, but behind the scenes, it loads a real build of SDL2 and lets that do all the hard work, just translating between what the app and SDL2 need.
This removes a massive code surface that no one is maintaining, eliminating a ton of Mac, Win32, and X11 bugs for old games, lets those games use newer APIs like Wayland and Metal and WASAPI, and gets apps no one is updating onto SDL2. Theoretically even the old Loki games could be using FULLSCREEN_DESKTOP and SDL_Render behind the scenes. :)
My hope is that someday soon, we'll be able to replace libSDL-1.2.so.0 in Linux distros with this little library. The current SDL 1.2, with all its ports and targets and assembly code and blitters is 172,041 lines of code; this will probably be less than 5,000.
One of the other benefits in modernizing applications is that old, software-rendered games now get pushed to the GPU. The app thinks it is drawing to pixels on an SDL_Surface, but sdl12-compat moves them to a texture to blast them to the screen. This has the nice effect of ancient 2D games going fullscreen with "free" scaling and running at a better framerate. They can use SDL_WINDOW_FULLSCREEN_DESKTOP, which doesn't mess with your desktop resolution and, as an added bonus, will slide into a macOS Fullscreen Space without taking your desktop hostage.
This wrapper is zlib-licensed and uses no code from "classic" SDL 1.2. This means 1.2-based games can live in places they couldn't before, like the Nintendo Switch.
So, in summary:
Want to run these games on Wayland without an X11 fallback? Done.
Want to run these games on Windows UWP? Metal? Direct3D 11? Done.
Want to run these games on platforms that conflict with the LGPL? Done.
Want to run these games on macOS Mojave with all the insane fixes we had to make to SDL2 just to keep things running? Done.
Want to update your dusty old SDL 1.2 package and find it's now several megabytes smaller? Done.
Overall, this is turning out pretty well. Next step, of course, is testing. It works (fairly) well with the handful of things I've tried: UT2004, TuxPaint, etc. If you have a 1.2 program--yours or anyone else's you have on your computer--please give this a test and report issues!