There are a number of limits which are useful for applications to be able to check, but which are not actually very useful to configure.

Take as an example maxVertexBufferArrayStride. In Vulkan, this limit can vary, but setting it to any value other than 2048 seems very niche:

• On Windows, it appears NVIDIA is always 2048, Intel is almost always 4095, and AMD is almost always 16383.
• On Android, only a few random devices (AMD, Intel, ImgTec) have values other than 2048.

The editors discussed this, and considered some possible approaches:

1. Remove some limits from GPUSupportedLimits+requiredLimits, and instead expose their base values as const values (e.g. GPUSupportedLimits.minMaxThing or GPUBaseLimits.maxThing)
   • Limits can be added to GPUSupportedLimits+requiredLimits later.
2. Make some limits "unconfigurable": keep them on GPUSupportedLimits, but disallow them from being specified as keys in the requiredLimits record<>. (Notably this prevents passing a GPUSupportedLimits object into requiredLimits.)
   • Limits can be changed from "unconfigurable" to "configurable" later.
3. Specify a list of limits for which the browser "must" or "should" only expose the base values on all adapters. This would leave them "configurable" but would only allow one configuration value (we clamp limits which are worse than the base), while reducing fragmentation. Alternatively this list can be de facto across browsers.
   • Limits can be removed from this list later.

For 2/3, also consider making GPUSupportedLimits constructible (without args) to provide the default limits, or exposing them in some other way.

Related: #1343