Be warned: this is a very worse-is-better, the-perfect-is-enemy-of-the-good proposal!

There are three possibilities on any given user's machine:

1. Hardware WebGPU with hardware WebGL2
2. Software WebGPU with hardware WebGL2
3. Software WebGPU with software WebGL2

This also applies for WebGL2 vs WebGL1 respectively. (WebGL1 vs Canvas2D can additionally have hardware webgl but software canvas2d)

For (1) we generally recommend WebGPU, but for (2) we definitely recommend WebGL2. (some apps without webgl1/2 backends may want/need to use software webgpu even if webgl1/2 have hardware therefore strictly more ideal)
For (3) though, we probably recommend using WebGPU again!

Originally, in the spirit of very literally designing a solution to match our user story, I considered GPUAdapter.preferWebGL2 but I feel like this approach (with WebGL2RenderingContext.preferWebGL1 and WebGLRenderingContext.preferCanvas2D) becomes unwieldy.

Instead, I think it might be easier to use if we just offer a totally qualitative [0.0-1.0] preference rating for each API (adapter?) that a user has, generally based on relative performance between that user's API choices. Yes this feels unsatisfyingly vague but we're not promising an API for comparing different users in absolute terms, but rather just a weighted recommendation between the choices on a single user's machine.

I think this also leaves room for users to reasonably choose modifications here via UA customization, as well as letting UAs generally provide (very) rough recommendations to websites about which backend to choose for that user.

This also leaves the door open for sorting and/or filtering for more complicated combinations.

Example A:
Imagine a system with software webgpu and webgl2, hardware webgl1 and canvas2d, with the recommendations 0.0/0.0/1.0/0.9. Here there's a preference for webgl1 over canvas2d, but also with canvas2d preferred above webgl2 or webgpu, the which are roughly equally slow/inefficient.

Example B:
Imagine a system with software webgpu, hardware webgl2/webgl1, and software canvas2d, with the recommendations 0.0/1.0/0.9/0.1. Clear preference for webgl1, but also a preference here for canvas2d over having to compile website shaders for the CPU, where we might expect canvas2d's fixed function SIMD operations to be better.

Example C:
Imagine a system with hardware webgl1+2, software canvas2d, and webgpu-emulated-on-webgl2ish-hardware, for which the webgpu/webgl2/webgl1/canvas2d ratings might be 0.9/1.0/0.8/0.0. (0.9 because maybe you expect overhead when e.g. a d3d11 webgpu implementation is given webgpu commands designed to take advantage of e.g. d3d12 features. (We expect this may be a fairly common configuration that Firefox runs in) You can tell these are well-ordered, and express the most likely preference for which API to choose. However, there's nuance in that if your website's webgl2 and webgpu backends are generally at parity with each other, the recommendation is to use webgl2 instead. Definitely avoid canvas2d on this machine.

While this API can feel unsatisfyingly vague, it offers the website a potentially-ordered set of recommendations for how to choose an API on a user's machine. Also, it's an easy-to-explain way to express this, such that it's even viable for users to reconfigure their UAs based on the user's preference for that machine. (Maybe they guess better than our UA's heuristics!)