glCopyImageSubData incorrectly rejects source dimensions smaller than compressed format block size

[Carter]

System Setup Information:
-----------------------------------------

System Used: ASUS Zenbook UX305CA
CPU SKU: Intel Core m3-6Y30
GPU SKU: Intel HD Graphics 515
Processor Line:
System BIOS Version: UX305CA.201
CMOS settings:
Graphics Driver Version: 26.20.100.7262, 27.20.100.8280
GOP/VBIOS Version:
Operating System: Windows 10 Home 64-bit
OS Version: 1903 (OS Build 18362.900)
API: OpenGL
Occurs on non-Intel GPUs?: No

Steps to Reproduce:
-------------------------------
1. Create two textures using GL_COMPRESSED_RGB_S3TC_DXT1_EXT with full mip chain
2. Call glCopyImageSubData for each mip level, using max(1, width >> level) for srcWidth parameter (same for height/depth)

Expected Results:
-------------------------------

glCopyImageSubData succeeds for all mip levels.

Actual Results:
-------------------------------

glCopyImageSubData fails when max(1, width >> level) is less than 4 (block size) with the following debug message:

"Error has been generated. GL error GL_INVALID_VALUE in CopyImageSubData: (ID:1655108141) Generic error"

Additional Information:
-------------------------------

NVIDIA drivers generate an error if the dimensions exceed the image dimensions at that level, i.e. if srcWidth > min(1, (width >> level)):

"GL_INVALID_VALUE error generated. The x values exceeds the boundaries of the corresponding image object."

In other words, an implementation that works on NVIDIA does not work on Intel and vice versa. glCompressedTexSubImage2D takes width/height arguments similar to glCopySubImageData, however both Intel and NVIDIA expect dimensions that match the image level, regardless of the block size, which makes me suspect that Intel is non-conforming in their implementation of glCopySubImageData. This post on Reddit discusses some ambiguities in the function specification: https://www.reddit.com/r/opengl/comments/gyie7h/glcopyimagesubdata_behavior_differences_on_intel/

Would be great if the debug messages could be improved as well, the message from the Intel driver in this case provides no more information than glGetError would which is a shame.