>How would a shader in your example look like that just wants to change the edge highlighting a bit (slice "light"?) but leaves the color and the FoW at default?

If you wanted different lighting for an object, you'd have to write a whole new shader. But the shaders will tend to be very short anyways, so I don't think that's a big problem.
And FoW will be applied automatically, there won't be a way inside the shader code to apply it manually. Just a flag to turn it on or off.

>Similarly, how could I change the overlay shading (slice "texture") then leave everything intact and then in the end make the overlay shine through FoW?

In the current proposal, there is no way to change a shader to do this, so if you wanted an overlay on top, you'd have to copy the whole shader modify it to serve that purpose.
And shining trough the FoW in that case won't be possible, an object would either be in front of or behind the FoW.

Concerning the overlays and changing the shading without replacing the shader, I had also thought about a different concept earlier, which would create a shading language more similar to the way #appendto and #include work in C4Script, but I thought it may be harder to implement and that the current proposal would be satisfactory, but now I see that loosing the flexibility to modify existing shaders is not good enough.

(The following is not a full concept, just what it might look like.)
E.g. if you wanted to add edge lighting to the current lighting you'd write something like:

#appendto DefaultShader

float4 getLigthing(...)  //maybe parameters, idk
{
  float4 defaultLighting = _inherited(...); //call the previous method without edge light
  float4 edgeLighting = //insert edge lighting code here
  return defaultLighting + edgeLighting;
}


That way, it would be simple to modify shaders afterwards and (at least to me) it will look clearer.
And it would be familiar to anyone familiar to C4Script.
Things like FoW could also be introduced as overloadable methods.
Also things like getUVCoords() could be overloaded to animate them, etc.

A documentation would then have to state which overoadable methods exist, in what order they are called, etc.

I like this style of writing everything in separate functions, because I think it is easy to read.
But a major disadvantage over the current slice system would be, that, as in you example where you wanted the overlay to be on top of the FoW would require some code duplication, so I'm not sure yet how that could work.

I'll have to think about this again...