In the Tessellation Evaluation Shader, it is unclear what gl_PrimitiveID refers to. The 4.3 specification says:
> The variables gl_PatchVerticesIn and gl_PrimitiveID are filled
with the number of the vertices in the input patch and a primitive number,
respectively. They behave exactly as the identically named inputs for tessel-lation control shaders.
In the TCS section, it says:
> The variable gl_PrimitiveID is filled with the number of primitives pro-cessed by the drawing command which generated the input vertices. The
first primitive generated by a drawing command is numbered zero, and the
primitive ID counter is incremented after every individual point, line, or tri-angle primitive is processed. Restarting a primitive topology using the prim-itive restart index has no effect on the primitive ID counter.
This makes sense in the context of a TCS. This makes much less sense in the context of a TES, because patches can be discarded by the tessellation primitive generator. Are discarded patches counted by the gl_PrimitiveID or not?

The intent is that the primitive ID in TES is the number of the patch from which the primitive was produced. When TCS is present, it will take an input patch (from the API) and produce a new output path -- that output patch should be considered to have the same primitive ID number as the input patch for the purposes of this test. If a patch is consumed by the tessellation primitive generator, it should still be counted.
This is definitely worth clarifying.

From OPENGL ES3.1 + AEP point of view
Summary of the following findings:
1. OPENGL ES3.1 GLSL: no PrimitiveID
2. (AEP) Tessellation without GS: draw command generates primitiveID
3. (AEP) Tessellation with GS: GS needs to generates new primitiveID, otherwise undefined.
4. No tessellation and no GS: we don’t need to support primitiveID in FS. (because ES3.1 GLSL has no PrimitiveID)
5. I don't see that primitiveID can be generated by TCS or TES.
From AEP point of view:
EXT_geometry_shader:
gl_PrimitiveIDIn, which is not an array and has no vertex shader
equivalent. It is filled with the number of primitives processed by the
drawing command which generated the input vertices. The first primitive
generated by a drawing command is numbered zero, and the primitive ID
counter is incremented after every individual point, line, or triangle
primitive is processed. For triangles drawn in point or line mode, the
primitive ID counter is incremented only once, even though multiple
points or lines may be drawn. Restarting a primitive topology using the
primitive restart index has no effect on the primitive ID counter.
gl_PrimitiveID is filled with a single integer that serves as a
primitive identifier to the fragment shader. This is then available to
fragment shaders, which will select the written primitive ID from the
provoking vertex of the primitive being shaded. If a fragment shader
using gl_PrimitiveID is active and a geometry shader is also active, the
geometry shader must write to gl_PrimitiveID or the fragment shader
input gl_PrimitiveID is undefined. See section 11.1gs.4 "Geometry Shader
The built-in output gl_PrimitiveID holds the primitive ID counter read
by the fragment shader, replacing the value of gl_PrimitiveID generated
by drawing commands when no geometry shader is active. The geometry
shader must write to gl_PrimitiveID for the provoking vertex (see
section 12.3) of a primitive being generated, or the primitive ID
counter read by the fragment shader for that primitive is undefined.
If a geometry shader is active, the built-in variable gl_PrimitiveID
contains the ID value emitted by the geometry shader for the provoking
vertex. If no geometry shader is active, gl_PrimitiveID contains the
number of primitives processed by the rasterizer since the last drawing
command was called. The first primitive generated by a drawing command
is numbered zero, and the primitive ID counter is incremented after
every individual point, line, or polygon primitive is processed.
Restarting a primitive using the primitive restart index (see section
10.3.4) has no effect on the primitive ID counter.
gl_PrimitiveID is only defined under the same conditions that
gl_VertexID is defined, as described under "Shader Inputs" in section
11.1.3.9.
EXT_tessellation_shader:
The variable gl_PrimitiveID is filled with the number of primitives
processed by the drawing command which generated the input vertices.
The first primitive generated by a drawing command is numbered zero,
and the primitive ID counter is incremented after every individual
point, line, or triangle primitive is processed. Restarting a
primitive topology using the primitive restart index has no effect
on the primitive ID counter.
The variables gl_PatchVerticesIn and gl_PrimitiveID are filled with
the number of the vertices in the input patch and a primitive
number, respectively. They behave exactly as the identically named
inputs for tessellation control shaders.
gl_PrimitiveID contains the number of primitives processed by the
shader since the current set of rendering primitives was started.
gl_PatchVerticesIn and gl_PrimitiveID are defined in the same fashion as
the corresponding input variables in the tessellation control shader.
Stephen Huang