Based on the analysis here: #3631 (comment)

Dawn's thinking before we added this limit was that it was incorrectly reported on AMD/NVIDIA/Intel devices, so we ignored it for those:
kainino0x/gpuinfo-vulkan-query@7cc9056
https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/dawn/native/vulkan/AdapterVk.cpp;l=385;drc=c2657b21d50938d4676aa6c87e44b3aa50c7f468
IF that's still correct even for higher storage binding limits, then adding maxFragmentCombinedOutputResources may actually not be doing anything for us. Here's a series of queries that look at whether it's filtering out any devices at higher storage limit tiers:

It seems maxFragmentCombinedOutputResources may not actually be buying us any hardware support, or avoiding any cases where we have to reduce other limits to stay under this.

Hence we should consider removing the limit. We can't actually remove it from the structs post-v1, but we can stop validating it. It would be nice to avoid overlapping limits where they're unnecessary, because they introduce some annoying complexity for users due to our strict enforcement of requested limits.

Other overlapping limits: maxBindGroupsPlusVertexBuffers, maxDynamicUniformBuffersPerPipelineLayout, maxDynamicStorageBuffersPerPipelineLayout, maxStorageBufferBindingSize, maxColorAttachments /maxColorAttachmentBytesPerSample, maxComputeInvocationsPerWorkgroup/maxComputeWorkgroupSizeX/Y/Z. Most of these won't be removable but are worth a second look someday. -> #4025