Out-of-range floating-point color values

[This](https://github.com/KhronosGroup/OpenGL-Registry/pull/534#issuecomment-1297111898) comment has a file that mentions all the cases I found but with links to related spec/extension.

---

> void ClearColor( float r, float g, float b, float a );
> sets the clear value for fixed-point and floating-point color buffers. The specified
components are stored as floating-point values. _{[[1]](https://registry.khronos.org/OpenGL/specs/gl/glspec46.core.pdf)}

So nothing is said about values, not in the `[0; 1]` range.

> #### Description
> glClearColor specifies the red, green, blue, and alpha values used by [glClear](https://registry.khronos.org/OpenGL-Refpages/gl4/html/glClear.xhtml) to clear the color buffers. Values specified by glClearColor are clamped to the range [0,1]. _{[[2]](https://registry.khronos.org/OpenGL-Refpages/gl4/html/glClearColor.xhtml)}

But in HTML pages for the same spec version, they are clamped?

---

Even more confusing in the case of `glColor4f`:

> Versions of the Color and SecondaryColor commands that take floating-point
values accept values nominally between 0.0 and 1.0. 0.0 corresponds to the minimum while 1.0 corresponds to the maximum (machine dependent) value that a
component may take on in the framebuffer (see section 2.14 on colors and coloring). Values outside [0, 1] are not clamped. _{[[3]](https://registry.khronos.org/OpenGL/specs/gl/glspec21.pdf)}

Now it's explicitly not clamped. But then Microsoft walks in and:

> Neither floating-point nor signed integer values are clamped to the range [0,1] before the current color is updated. However, color components are clamped to this range before they are interpolated or written into a color buffer. _{[[4]](https://learn.microsoft.com/en-us/windows/win32/opengl/glcolor4f)}

Well, isn't this an implementation detail? (I mean when the clamping is done, as long as before interpolation)
And OpenGL API is supposed to only care about the apparent behavior...

---

Generally, from a few experiences with old OpenGL I remember - all the floating point color values seemed to be clamped.
So it was quite a revelation to learn, for some functions none of the original .pdf specs define how out-of-range color values should behave.

I would understand if `glClearColor` with out-of-range values was implementation defined...
But since `glColor4f` is explicitly said to not be clamped, I expect a line between two points with colors (2.0; 2.0; 2.0) and (0.0; 0.0; 0.0) to have a fully white point in the middle and descend to full black towards the second point.
However, what I observe is a gradient starting at the first point - as if values passed to `glColor4f` are in fact clamped to be (1.0; 1.0; 1.0).

Start with the file linked in the referenced pull-request comment, then compare the cited OpenGL specification PDFs and glClearColor/glColor4f reference pages. Trace each out-of-range color case and record where the sources disagree. Done means the affected specification or registry documentation has a clear, authoritative statement about the behavior.

Written by the indexing model from the issue text.