The driver could try to replace its kernel module when updated, but what if the kernel changed during the package update?
The loaded kernel is never changed until reboot. DKMS will (should) build the kernel modules for every installed kernel. So updating the kernel is not a problem. The problem is that the currently loaded kernel module is not reloaded. I assume, it cannot be reloaded because this would mean any running GUI applications would need to be closed.
You can’t just remove the ABI check, nothing would work. You could keep a small stub that’s ABI-compatible with just the necessities, and that’s basically what the driver does to report an error on context creation instead of just crash.
As I said, this works with drivers from other vendors. Whether they maintain a stable ABI or have some other solution - I don’t know.
I suspect that most of the time ABI is actually compatible between different versions of Nvidia drivers, so at least minor updates could be made successful relatively easily, IMHO. Though, that still leaves the question what to do when ABI has to change.
If the driver tried to pull its GLX driver out of memory on an ABI mismatch, all the programs still running from the dynamic loader would suddenly crash.
I’m not asking for this. I don’t even think this is possible. Basically, I see two ways to solve this:
Make the userspace components ABI-compatible with the kernel driver regardless of the version and remove the ABI check. I think, this is the approach taken by Linux kernel and other driver vendors.
Make sure the current session works with the old userspace components until reboot. I’m not sure how exactly to do this. Maybe make the necessary OpenGL libraries as hardlinks, which get updated on reboot. Or use some sort of system daemon that keeps the old libraries from being deleted until reboot.