Core-profile OpenGL context with compatibility-era GLSL shaders: which mixes are actually portable?

Short answer

None of the mixes you describe are portable. A core-profile context is not guaranteed to reject a shader declaring an older non-core #version — acceptance is driver-dependent — so "it compiled on our test machine" tells you almost nothing. The only portable configuration for your constraints (Mesa, a proprietary Windows/Linux driver, and macOS) is: core-profile context everywhere, all shaders at #version 330 core (or 150 core if you must support older macOS-era code), a real VAO always bound, and zero fixed-function calls. Everything else is luck on a lenient driver.

Is an old #version guaranteed to fail in a core context?

No. The specification ties shader language validity to the context profile, but enforcement varies widely:

• Mesa and macOS (which only exposes core profile at 3.2+, capped at 4.1) enforce strictly. Legacy built-ins like gl_Vertex, gl_ModelViewMatrix, and gl_FragColor fail to compile.
• NVIDIA's proprietary driver is famously permissive and will often compile compatibility-era GLSL in a core context without complaint.

Also note that a #version directive without the core keyword defaults to compatibility semantics for versions that support profiles — omitting the keyword is not a request for core. So a green build on an NVIDIA dev box proves nothing; treat any successful legacy compile as non-portable luck, not a contract.

Which profile-dependent defaults break a shared draw path?

Three, in rough order of how often they bite:

1. Default VAO. In core profile, VAO 0 is not a valid binding for drawing; you must create and bind a real VAO. In compatibility profile, VAO 0 works. A draw path that never binds a VAO looks fine on compatibility or lenient drivers and silently renders nothing (or errors) on core and macOS.
2. Fixed-function state. glMatrixMode, glBegin/glEnd, glLight*, texture environment, and client-side vertex arrays are removed in core and generate GL_INVALID_OPERATION/GL_INVALID_ENUM. Any shared code touching these breaks only under core.
3. sRGB framebuffer assumptions. This is less a profile rule than a context-creation detail: whether the default framebuffer is sRGB-capable depends on pixel-format/framebuffer attributes (e.g., GLFW_SRGB_CAPABLE, WGL/GLX attributes), not the profile. Code assuming a linear default framebuffer produces washed-out output when the window system hands you an sRGB one, and this varies by platform. Verify by rendering a known mid-gray gradient on each target.

Is checking the profile mask sufficient?

Necessary, not sufficient. Querying GL_CONTEXT_PROFILE_MASK and GL_CONTEXT_FLAGS (forward-compatible bit) immediately after creation tells you what you actually got — drivers may return a different version or profile than requested — but it says nothing about how lenient that driver's shader compiler is. A core context on NVIDIA still compiles shaders Mesa and macOS reject.

So you need a small per-driver validation pass, but it can be cheap:

• Log GL_VERSION, GL_CONTEXT_PROFILE_MASK, GL_CONTEXT_FLAGS, and GL_SHADING_LANGUAGE_VERSION on every target stack at startup.
• Compile one deliberately legacy shader (uses gl_FragColor, no core keyword) under the core context on each driver to map which stacks reject it; treat the strictest result as your baseline.
• Enable a debug message callback (glDebugMessageCallback via GL_KHR_debug or core 4.3+) in development builds to catch missing VAO binds and removed-state usage at runtime.
• Enumerate extensions per context with glGetStringi/GL_NUM_EXTENSIONS — never glGetString(GL_EXTENSIONS) in core, and never infer extensions from the advertised version.

Recommendation

Standardize on #version 330 core for every shader, always bind a VAO, strip fixed-function calls, and gate optional features behind runtime extension queries. That gives you one draw path that behaves identically on Mesa, proprietary drivers, and macOS. One caveat worth flagging now: macOS OpenGL is deprecated and frozen at 4.1 core, so if macOS is a long-term hard requirement, plan for a Metal/ANGLE/MoltenVK backend rather than expanding your GL investment there.