takes gl_FragCoord and returns a vec3 with world coords as determined by the interpolations from the vertex shader.

That’s not possible.

First, even if you’re using the standard OpenGL matrices, there is no “world space”. There’s object space, which is what the vertex attributes store. There’s eye space, which is the space of vertex data after transform by the modelview. And there’s clip space, which is the space of the vertex data after transformation by both the modelview matrix and the projection matrix.

So OpenGL does not have the necessary information to go to world space. But let’s assume you meant eye space, since that’s typically where lighting happens.

Second, you do not need to use those matrices. GLSL has exactly one function that is dependent on the standard, fixed-function matrices: ftransform(). And that is only necessary if you need the GLSL vertex shader to be invariant with a fixed-function vertex processor. Outside of that, you can just do the matrix multiplications yourself.

And what if you’re using your own matrices? Without the standard matrices, the closest that OpenGL could give you is clip space. That is, the values you wrote from the vertex shader.

Lastly, why would you need it? OK, there are impostors. But outside of that, or a completely artificial example like this, what practical use is there for reverse transforming gl_FragCoord. There’s a practical use for reverse transforming a user-defined vec4 who’s values are defined as though it were gl_FragCoord. But the input vec4 would not have to be specifically gl_FragCoord.

And even that would require uniform resources.

OpenGL, and D3D for that matter, has been slowly discarding fixed-function stuff for flexible shader code. So why backtrack with something like this? It’s not going to be any faster than what you could do on your own.

making it an extra step to pass in the view port variables via an ‘in’ variable.

The viewport values do not change per-fragment, so there’s no point in making them vertex shader outputs/fragment shader inputs. Those should be uniforms. You could even have a simple uniform buffer set up for that, one that is common to every shader you use. It could also store other common things like the projection matrix and so forth.