There are several SDL games that depends on an older SDL12.DLL to run.
Regarding old versions I recently considered a SDL DLL directory tree (due to disk full-errors) for each version of e.g. FSLIB.DLL, but then you'd still have to manage LIBPATHs, it's an own "standard", and the gain would be about 10 MiB.
i don't know why compiling of apps/games (and/or the DLLs) is excluded as an option. If the apps/games and DLLs are frozen, then I may give that directory tree for old SDL DLLs a try. But only to gain about 10 MiB.
I've got 16 FSLIB.DLL candidates, and 36 SDL*.DLL candidates. Excluding the NetLabs-ones. I cannot recall any significant SDL-related issue with older, frozen apps/games which would require a SDL update, but YMMV.
If you wouldn't have excluded recompiling, then you could have contacted the author(s). A recent DLL-related improvement is the browser Links/2, which no longer uses own DLL files like a JPEG.DLL and a Z.DLL, but without its author having to rewrite related (ported) code to join the NetLabs SDL programme.
Of course the SDL directory tree would be as simple as
x:\SDL12.DLL\188402 bytes\SDL12.DLL and matching BEGINLIBPATH and LIBPATHSTRICT settings for the game Amoebax and for the emulator ZSNES. Both are using that SDL12.DLL file, and an identical FSLIB.DLL file. I don't know if you can use both apps/games at the same time then.