Pasteing discussion from Discord to start the discussion here...

Should the user be expected to use the GL types as defined in bindings.zig, or should be standard Zig & the types defined in the wrapper?

The wrapper "forwards" types defined by the bindings. A wrapper user shouldn't need to access any definitions from bindings.zig directly.

Some enums (for example, the debug output filter) have an element which may be present but would only be provided to one function but not the rest (e.g. GL_DONT_CARE) should these be part of the enum, defined in-line, part of some extended enum, or from time-to-time allowing a null value to define this extra behaviour?

Ideally functions should only take enums sets where all the members are valid for that function. Note that for some functions enum types are defined inline. And there are probably some mistakes present currently. From the opposite angle wrapper.meta.mergeEnums can be used to merge enum sets.

When data is going to and from OpenGL, what type should generally be preferred? A pointer + offset, or a []u8? This is mostly a fluency question. Textures currently use opaque pointers, while buffers use arrays. Consistency would be nice to have.

Slices should be preferred to pointer+len unless that prevents some functionality. For example glBufferData can be passed a size and a nullptr to allocate memory of size but not write to it.

Getter functions such as getProgramiv seem to generally return their result by value, while creation functions return by reference (in particular, the single-value overrides). For fluency sake, would it make more sense to have both return by value?

The current convention is that gen* procs return by reference and create* procs return by value. For get* procs I'm not sure what is best, there is an argument for both.