Possible error in GL_KHR_shader_subgroup.txt : Useless subgroupMemoryBarrier functions?

The function `subgroupBarrier` performs both an execution and a full memory barrier

> The function subgroupBarrier() enforces that all active invocations within a
> subgroup must execute this function before any are allowed to continue their
> execution and the results of any memory stores performed using coherent
> variables performed prior to the call will be visible to any future
> coherent access to the same memory performed by any other shader invocation
> within the same subgroup.

I wonder if there is any usefulness for `subgroupMemoryBarrier` functions since they do not perform an execution barrier :

> The function subgroupMemoryBarrier() enforces the ordering of all memory
> transactions issued within a single shader invocation, as viewed by other
> invocations in the same subgroup.

However, it is written that the invocations within a subgroup run in parallel :

> A subgroup is a set of invocations exposed as running concurrently with
> the current shader invocation. The number of invocations within a
> subgroup (the size of the subgroup) is a fixed property of the device.

Since they are running in parallel, is it useful to have an execution barrier? If it is not needed, the `subgroupMemoryBarrier` functions became useful, but the `subgroupBarrier` function becomes useless.

However, if we do need an execution barrier within a subgroup, I think it is necessary to synchronize other operation like shuffling as well. However, it is probably implicit like `__shfl_down_sync` in CUDA.

So,

- is the `subgroupMemoryBarrier` functions are useful and `subgroupBarrier` useless?
- Is the `subgroupBarrier` useful and `subgroupMemoryBarrier` functions useless?
- Is the specs are going to change (like for `barrier` and `memoryBarrier` functions for a local group)?
- Is my understanding really bad?

Read GL_KHR_shader_subgroup.txt, starting with the definitions of subgroupBarrier and subgroupMemoryBarrier and the cited subgroup execution model. Determine whether the two functions have distinct useful semantics and whether the specification needs wording changes; done means a settled specification decision addressing the listed questions.

Written by the indexing model from the issue text.