Anything else also would be insanely hard.
Just trying to "store the GPU state" on a system with AMD GPU and resume it on a system with a NVIDIA GPU (or just old GPU and new GPU from same Vendor) is likely around the area of "lets treat it as impossible".
When you are writing a program, there are a lot of states, some of them are visible to code, some of them are not, some of them are about game logic, some of them are tight to machine physical states. And you are almost not going to separate them unless specifically designed it to.
And that is called save system.
But the problem of save system is: that is slow to load, because you need to initialize everything from ground up. All the textures, stage data, enemy entities will need to be reloaded even it is technically fine to reuse all of them.
And that is what xbox do(I think steam is unlikely to copy that?)
The idea of quick resume is to sacrifice storage spaces, just store everything(even things tight to hardware) to skip the initialization process for fast loading, which is completely opposite for what steam want to do.
Until now, only xbox implemented that (on same machine only)
But I just can't see it working across OSes.
Maybe if you limited it to same ARCH (or even vendor, AMD here) and dump everything but use some tricks wrt. GPU state? (And also not dumping OS discardeable caches, no idea if that is used by games though).
checkpoint restore of gpu state is much further along than you credit.
You really just need to dump textures and set up a matching context, which at worst should require an indirection shim to translate handles if they are stored by the application but generated by the driver with no way to force custom values during object creation (like how Linux allows custom PIDs for checkpoint/restore and other replay tech like rr).
Even if have a perfect wrapper that achieves all that you now have to save all application-supplied texture and shader data in the original form even where that memory could normally be freed after translating it to GPU-specific formats.
But "restricting yourself to a shared subset of OpenGL" alone already makes this unviable for anything demanding as it also means restricting yourself to the lowest common denominator for all limits including VRAM size, maximum texture sizes, essentially guaranteeing your solution to run worse on both systems.
The texture size issue I don't see as a problem (I thought we grew out of that being an issue years ago?), and the VRAM issue shouldn't be that hard, as games tend to not use spare VRAM for dynamic time-memory tradeoffs (unlike OS kernels with their pagecache).
On top of that, it's not like you need this functionality to deliver top performance from games that don't want to play their part to make this efficient. Working seamlessly at "just" 30% less FPS should already be very useful.