Hm, now that I think of this more, it has potential to make some things not work so well, so I lean on not adding it after all. I also remember that I've possibly thought of it before.
For example OpenGL texture rendering needs to flip the projection vertically, which would under the simple scheme I outlined in the last post, just overwrite the custom set matrix. Also screen ray calculation and occlusion software rendering need the projection matrix too, but it's always for the D3D-like depth (from 0 to 1) so an OpenGL matrix would produce incorrect results there, and then you might wonder why screen picking or occlusion doesn't work as you expect.
In short I don't plan to spend energy on this now. A cleanly implemented PR that avoids these shortcomings would be welcome though, as usual.