xcb_generate_id is a BadIDChoice trap

Consider the race described in libx11#118. A calls xcb_generate_id, which returns, but then gets scheduled out. B calls xcb_generate_id and triggers the xc_misc_get_xid_range path; the returned range includes the value returned for A's xcb_generate_id call. Then A runs again, and the subsequent resource-creation request either fails or (more likely) succeeds laying a trap for some later request.

I'm having some difficulty coming up with a way to work around this. Even if you annotate every single resource-creation request, (fix the codegen to) log generated-but-not-created XIDs in the xcb_connection_t, and filter them out from get_xid_range results, you would still need to know when those creation requests were sent in order to remove them from the pending log. Since the creation requests in xlibs are just open-coded with GetReq, you'd need to inspect the request buffer at socket handoff time to find them, which is probably doable but also probably extremely unpleasant. Alternatively, port every single xlibs library to invoke xcb instead of ever calling GetReq, which is also doable but also a significant amount of work.