It's essentially a complexity issue. Adding more inputs, removing the input fields would make the node be a bit too complex for new users. I suppose the input fields could go grey if you connect a UV speed input. I will think about it :)

The reason the coordinates are from -1 to 1 by default is because those are the easiest/quickest coordinates to access, anything else is extra math. I want SF to be optimized, while still giving you lots of control.

The distortion you're getting is because the screen coordinates are per-vertex at the moment, which is a known issue. There will be a setting to use either vertex or pixel coords. A workaround at the moment would be to use a more tessellated plane, either with a more detailed model, or using DX11 tessellation.

Perhaps, yes! It will have to wait until after the initial release though :)

You can use Light wrapping in the meantime to approximate the SSS effect

This was implemented in Alpha 0.10

Cool, I got the issue then! I will have to add some warning instead of allowing the entire parsing process to crash :)

Thanks for the help debugging this!

Does it happen to shaders without a cubemap node?

It's trying to get one of the faces of the cubemap - are all faces marked as readable as well?