It introduces the mechanism, so yes it does not do much. The whole series will be much longer but we're often told to keep MRs small. The change at the very least is an improvement to wglShareLists implementation, which currently involves a complicated context state tracking and recreation. Although the current code is enough for the few games we have found to be using wglShareLists, it is not correct wrt actual wglShareLists behavior, and cannot be because of impedance mismatch with host GL API. I chose not to go through object name wrapping at the time because it was a larger impacting change, but after spending more time studying the options for framebuffer rendering, it seems now that it is unavoidable if we want more freedom with object allocation on the unix side. As discussed elsewhere, it is also necessary so that we can allocate GL objects in application rendering contexts on the unix side to implement our own GL swapchains, without breaking application assumptions about object names. GL allows most objects to be implicitly allocated, as https://gitlab.winehq.org/wine/wine/-/merge_requests/10739 tests shows, and many applications are hardcoding the object names they use without any explicit allocation. We cannot safely allocate GL objects unless they are isolated and hidden from application objects, and because of other GL context sharing and destruction semantics we will also have to track and isolate every shareable object name, and end up with a single global GL object namespace on the unix side. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10870#note_140538