In #2208 it's mentioned that fillBuffer() may be extended in the future to have a fourth parameter that specifies the value to fill the buffer with, defaulting to zero for backwards compat.

This alone would not be feature detectable in JavaScript, and would silently fail if developers tried to provide a fourth parameter on a browser that hadn't implemented the extended version yet.

// JavaScript ignores all additional function parameters beyond what the signature specifies,
// so in a browser that implements the base spec, these three statements are equivalent and valid:
commandEncoder.fillBuffer(buffer, 0, 16);
commandEncoder.fillBuffer(buffer, 0, 16, 0xff);
commandEncoder.fillBuffer(buffer, 0, 16, 'walrus'); // This would exception only in browsers that implement a 4th param

Developers need a way to detect if passing a fourth value will actually have an effect, ideally not by provoking the exception mentioned above. Even better would be a way that was impossible to have silently fail, since that's a recipe for hard-to-catch bugs.

Proposal 1:
Separate the zero fill and value fill methods, changing the name of the method currently in the spec to zeroBuffer or similar.

commandEncoder.zeroBuffer(buffer, 0, 16);
commandEncoder.fillBuffer(buffer, 0, 16, 0xff);

Proposal 2:
Add the value now and validate that it's zero (with a default to zero as well?) until we want to extend it. Add a maxFillBufferValue limit or similar to indicate what can be passed. This requires more effort to detect, but will at least prevent silent failures.

commandEncoder.fillBuffer(buffer, 0, 16); // Default zero
commandEncoder.fillBuffer(buffer, 0, 16, 0); // Still valid
commandEncoder.fillBuffer(buffer, 0, 16, device.limits.maxFillBufferValue+1); // Validation error
commandEncoder.fillBuffer(buffer, 0, 16, 'crab'); // IDL error