EXT_provoking_vertex: only exposed if `FIRST_VERTEX_CONVENTION` is *more* efficient, or *at least* as efficient?

It's great to see EXT_provoking_vertex as a draft extension already! I may volunteer to implement it in Firefox, and there's one line I want to draw attention to:

> Implementations SHOULD only expose this extension when FIRST_VERTEX_CONVENTION is more efficient than the default behavior of LAST_VERTEX_CONVENTION.

I know of three types of platform API that WebGL2 may be layered over:

* One API that only supports `LAST_VERTEX_CONVENTION`, i.e. OpenGL ES. With the current wording, it's clear that this extension should not be exposed here.
* APIs that only support `FIRST_VERTEX_CONVENTION` natively, where the default `LAST_VERTEX_CONVENTION` must be emulated, i.e. Direct3D and Metal. With the current wording, it's clear that this extension should be exposed here.
* APIs that support both vertex conventions natively, i.e. Vulkan (when VK_EXT_provoking_vertex is available) and desktop OpenGL. This is where it gets a bit awkward.

In the last type of API, an application developer can currently expect both conventions to be equally efficient. But in the case of OpenGL, where both conventions are core and must be implemented regardless of their efficiency, this might not *always* be the case. The first-vertex convention has won out among current-generation graphics APIs, including Vulkan and WebGPU. I know of one currently existing OpenGL driver that emulates `LAST_VERTEX_CONVENTION`, Mesa's d3d12 driver, and none that emulate `FIRST_VERTEX_CONVENTION`. I don't think it's likely that this trend will reverse.

From an implementor's perspective, exposing EXT_provoking_vertex above the last type of platform API (and implying to apps that `FIRST_VERTEX_CONVENTION` should be preferred) seems like a safer bet to me than not doing so.

Of course, one counterpoint to this from a standards perspective is that leaving Android (where I believe WebGL is still usually layered over OpenGL ES, and certainly so on non-Vulkan-capable devices) as the only major platform without this extension would put it in an awkward position.

Start with the EXT_provoking_vertex draft wording quoted in this issue and compare the three platform API cases it identifies: OpenGL ES, Direct3D or Metal, and Vulkan or desktop OpenGL. Review the efficiency rationale and determine whether the exposure guidance needs a standards decision; no files or tests are named, so completion would be an agreed clarification to the specification.

Written by the indexing model from the issue text.