Using GL_ARB_shader_viewport_layer_array in tess evaluation shader results in Geometry capability of spir-v

I'm using the glslc to compile glsl shaders to spir-v and stumbled upon layered rendering without geometry shaders (which is crucial for targeting MoltenVK backend). There is an [extension](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_shader_viewport_index_layer.html) for that in Vulkan and corresponding [extension](https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_shader_viewport_layer_array.txt) in glsl.
I'm not really sure how the extension mechanic is implemented in glslc, but I've tried the following code:
`#extension GL_ARB_shader_viewport_layer_array: require` in tessellation shaders and it seems to do the job: I'm now able to write the gl_Layer in tess evaluation shaders. But using this extension results in tess evaluation shader having "Geometry" capability enabled, which in turn triggers Vulkan validation layers errors. Though the Vulkan extension states that

> This extension allows variables decorated with the Layer and ViewportIndex built-ins to be exported from vertex or tessellation shaders, using the ShaderViewportIndexLayerEXT capability.

Hence I'd expect the generated spir-v binary to have ShaderViewportIndexLayerEXT capability. Is this intended behaviour of compiler? Can I somehow manipulate the capabilities of binaries through compiler options?