Does Vulkan have the equivalent of OpenGL's separable shader program and pipeline? If you have a shader pipeline in OpenGL that goes something like the following:
// Pseudocode

// FragmentShader
// in vec3 inVertexPosition;
// in vec2 inTexCoords
// 
// int main()
{
    // Sample texture coordinate and write to fragment out
}

Then you have another fragment shader that does something a little different:
// int main()
{
      // Sample texture, calculate noise and mix with texture colour
}

In OpenGL if you want to execute this second shader you only compile this second shader and bind to the fragment shader stage of the shader pipeline. You can then create another a different vertex shader and attach that to the vertex shader stage whenever you need it.
Let's just say I have 5 vertex shaders and 5 fragment shaders, in OpenGL (because it supports separable shader objects) you only need to compile 5 x 2 = 10 shaders. However, as in Vulkan, as far as I know it doesn't support it, which means you have to compile 25 programs if you want to use each combination.
Does Vulkan have the equivalent of the OpenGL separable shader objects, or are there any plans for it? They seem just so much more flexible.
I've thought about being able to bind shader stages in my code, and then every combination of shader stages could be mapped to a single compiled program, however I don't think the mapping could be searched efficiently. I'm not sure. It seems being forced to compile an entirely new pipeline when inserting a shader stage is wasteful when you make many shaders.
It seems in principle this is like compiling a new program every time you created a new function.
Does Vulkan have the equivalent of the OpenGL separable shader objects, or are there any plans for it? They seem just so much more flexible.

It would be &quot;so much more flexible&quot;. But Vulkan is a low-level rendering API. It's job is to give you access to the hardware as close to the metal as possible; user-convenience isn't even in the top-5 goals for the API.
Putting all of the context state into one gigantic, immutable (more or less) object gives the implementation all the power it needs to make your code fast. Forcing implementations to deal with stitching together shaders would make implementations more complicated (and another goal of Vulkan is to be relatively easy to implement).
The best way to solve this (where possible) is to just have fewer shader variations. Use uniforms/push-constants to detect what variations you want to use, then have conditionals based on them. Obviously this can't be done in every situation, but the uber-shader approach is the way to handle it to the degree possible/reasonable.