Thanks so much for taking the time to create and post this information, but honestly, I don't need to "see a figure."  I've done actual render tests.  I've seen the difference between sRGB correction and GC in images.  I saw it when Bagginsbill posted his tests long ago, and I did several of my own tests.  I don't rely on theory alone.  As someone's sig says, "In theory, theory and practice are the same.  In practice they aren't."  And pretty much no one can tell a visual effect from looking at a table of numbers.  I do render tests and I do lots of just plain work with materials and lights (real use being to controlled experiments what theory is to experiments).  

I try to only post what's worth posting, but I think I have a representative enough and decent enough gallery to show something of what I've learned over the years.  As I'm sure you've done with your own gallery, which is very fun and interesting but small enough that I'm guessing it's pretty edited.

Also, I've done tests on my "studio" prop.  It's basically a cube with the normals pointed inward.  It doesn't cast shadows.  It shades completely differently with linear workflow than with regular workflow, as well as differently with sRGB and with GC.  So unless you mean no shading when you say no shadow, then I can't say I've seen the results you seems to expect.  Linear workflow means linearizing input and correcting output after calculation of the linear processes like shading (not casting shadows, just diffuse shading).   Correcting final output is what GC does.  As with any process, it doesn't matter what happened before that point, just what the results were that get fed into the new step.  So when that final conversion back to sRGB space happens, it doesn't matter how the colors that are input into that conversion were produced.

The only time there will be no change in results is when there's no calculations after linearization.  As a function, it goes Correct(Shade(Linearize(color))).  The color is only unchanged at the end of the process if the Shade(color)  = color.   My original point is that it really doesn't matter to the function Correct(y) how y was produced.  So in practice, it's not just about low light images.  The final Correct function doesn't care if y was produced by a low light on a pure white diffuse surface, a medium light on a medium grey diffuse surface on a part of the surface positioned away from the light,  a bright light casting a shadow onto a white surface, or a bright light shading a surface that has a dark diffuse color.  The relevance to this discussion being that in carodan's original examples, which seem to use a bright light and one sphere with a medium diffuse color and the other with a bright diffuse color, the difference between sRGB and GC would affect the end result as it shaded to black.  Basically, it's not just an issue when you turn down the lights, though that's when it becomes most obvious because so much of the scene is affected. 

And while I call that middle function Shade, really, it's any type of linear calculation.  Adding, subtracting, multiplying, etc. Just in my opinion, I think it would makes more sense to be able to mark inputs and images nodes for linearization rather than only being able to mark image nodes for exclusion.  I've never, in all my years of using Poser, seen a material that needed lots of colors linearized, but I know of tons that are put together assuming that color math and Blending masks are linear processes.