This has been discussed some in #2748 and #2535.
The desire is to provide an API for smaller applications that provides the preferred format without requiring the application to get their preferred-format usage just right - i.e. testing on rgba-preferred and bgra-preferred systems.

This format's capabilities would be defined such that its underlying ordering can't be observed, and therefore can be either rgba8unorm or bgra8unorm. Only copyBufferToTexture/copyTextureToBuffer/writeTexture can observe the ordering. It would have the intersection of the capabilities of rgba8unorm and bgra8unorm (so, can't be used as storage).

For now I'm calling it "rgba8unorm-unordered", open to later bikeshedding.

Open questions:

• Can you createTexture with this format, and can you use it with copyTextureToTexture?
• Should writeTexture "polyfill" to allow writing as if it's rgba8unorm, or be disallowed?
• Should copyBufferToTexture/copyTextureToBuffer "polyfill", or be disallowed?
• Should there be multiple magic formats with different capabilities, e.g. "rgba8unorm-unordered"/"rgba8unorm-unordered-storage"?

My proposal: Have magic formats fully resolve to either rgba8unorm or bgra8unorm in every way (except we enforce the same capabilities either way). You could use it with createTexture, copyTextureToTexture. Don't polyfill anything.

Unsure about adding a second format with storage support; it's less critical. (Applications that need storage can pick a format based on getPreferredCanvasFormat + presence of the "bgra8unorm-storage" feature.)

(Note: Originally I was thinking this wouldn't support the COPY usages at all. I realized that's not necessary.)