In #69, it was determined that copyBufferToBuffer (and thus writeBuffer) needed to have the size be a multiple of 4 because of this limitation in Metal:

In macOS, size needs to be a multiple of 4, but can be any value in iOS and tvOS.

(I actually had it in my head that the limitation was more than just Metal, but when I went to look this up, I found that apparently it was Metal-only the whole time.)

However:

• If this limitation doesn't exist on iOS and tvOS, it seems very likely that it also doesn't exist on Apple Silicon Macs, meaning the limitation is aging out and we should aspire to drop it.
• A user of WebGPU has told us that they rely on unaligned sizes without issue. I don't know yet whether they have tested this on Intel/AMD/NVIDIA Macs, and whether the Metal validation layers allow it. (Though I don't know why it would be specific to Intel and/or AMD and/or NVIDIA, given that Vulkan, D3D12, and OpenGL do not have this restriction.)

Notably, copyTextureToBuffer does not have this limitation, so I think that even if this is a real limitation, it could be worked around by translating copyBufferToBuffer into copyBufferToTexture+copyTextureToBuffer (and writeBuffer into writeTexture+copyTextureToBuffer). Even better, I think it's possible to work around without an extra copy by using a texture view into a buffer (conveniently macOS 10.13+, the same we already require). If this is an aging restriction, then a workaround would let us drop the restriction from WebGPU right away, even if it has overhead.

BTW, map ranges (mapAsync, getMappedRange, mappedAtCreation) also have this limitation. I have not checked whether that just came directly from copyBufferToBuffer, or if there were other backend limitations that resulted in that.