For the same reason you can't get a list of all buffer objects. Or a list of all texture objects.Why should that information not be made accessible?
You are expected to take certain responsibilities on for yourself. And this includes keeping track of what you have actually done with the system.
How do you delete your buffer objects after you're finished using them? How do you delete your textures after you're done with them?That apart from the need to delete the named strings once everything got compiled.
If I'm writing a module that has dependencies on what someone else has done, then if they haven't done it yet, they deserve to get broken behavior. Garbage in, garbage out.If writing a module concerned with shader stuff one might not necessarily know what sources were loaded. That information would eiher have to be passed to the module by the user or can be queried.
And personally, I would say that a module that is that dependent on the specific initialization someone else did is bad design. If the module needs certain things to be loaded, then it should be responsible for loading them.
Also, I think you're getting somewhat confused with the notion of how these things work. The point of the #include mechanism is that you don't need to build string prefixes and so forth when you use glShaderSource/glShaderProgram. You just pass a single string, which #includes what it needs. The C/C++ code should neither know nor care about what any particular shader #includes.
So I don't see why any C/C++ code would ever care one way or the other. It's up to the various shader strings to know where their stuff is, and it's up to whoever sets up the library of includes to put them together.