And I’m saying that conventions like that are not OpenGL’s job, nor the job of any graphics API that considers itself vaguely “low-level”. Graphics APIs exist to expose hardware. They have “a lot of binding points available” because the hardware has “a lot of binding points available”. You’re supposed to be able to use all of them at once.
Similarly, it is not the job of assembly to decide which registers should be pushed by the caller and which registers should be pushed by the callee. That’s a convention established by all developers working within the same project.
Furthermore, while it solves a portion of the problem, it doesn’t really solve the totality of it. There is a lot of state out there which isn’t based on binding points. Blending, viewports, etc. The API used to have ways of preserving such state (push/pop), but that was removed because it was painful to implement and not particularly useful to most users.
Note that command buffer APIs make it fairly simple to reset lots of resource state, since they bundle large blocks of resource state into descriptor sets. Of course, this also makes it clear from an API perspective that there is a non-trivial cost associated with this, so maybe try to structure your code to avoid or minimize it. That is, instead of having modules do whatever they want and you and they resetting state every time, make modules conform to what you want.
The entire point of putting people on “a team” is so that they can communicate and work together. So if they’re not talking, I would not characterize their relationship as being “parts of a team.”
In order for two or more people to work collaboratively, there has to be some discussion between them about the interface between their respective components of the project. At the very least, they have to agree on function names and parameters; otherwise, neither side can even talk to the other, right?
That agreement would also include some idea of what those functions do, right? I mean, if one side doesn’t know what a function will accomplish, when would they call it? I’m saying that part of that discussion will necessarily involve hashing out how each side is allowed to interact with OpenGL. They have to deal with what state they both expect the system to be in before the call and after it. They have to know whether or not calling it will provoke rendering. Etc.
That discussion will necessarily include state management, like binding points for objects.