glTexImage behavior when LOD higher than expected by dimensions

Hi,
I'm looking into issue when 'glTexImage' functions are called with 'level' param higher we expect based on LOD0 texture size, and problems consequent from it.

GL 4.6 spec '8.14.3 Mipmapping' defines:
1)each LOD has a resolution lower than the previous one,
2)there is X LODs in a mipmap, where X=floor(log2(max(width, height, depth)))+1

In case of 'glTexStorage' functions, GL_INVALID_OPERATION error is required by spec in case LODs number is higher than calculated value based on dimensions. And result of 'glTexStorage' is a set of _immutable_ LODs.

I understand that 'glTexImage' is more flexible tool, which can be called with any LODs order and size, since they're all _mutable_.
So I assume that we can not require any GL_INVALID_VALUE/GL_INVALID_OPERATION for 'level' param other than already specified. Is that right?

My main question is: when having inconsistent LODs set in texture(specifically smallest LOD 1x1px duplicated multiple times),
1) what data we should expect in texture levels?
2) what behavior to expect when using other functions on this data (glCopyImageSubData, glGetTexImage, etc)?

Example: to create a 32x32px texture, we put our data into all 6 expected mip-levels by 'glTexImage2D', and 1 time more unexpected.
Now we have texture with following levels LOD0:32x32, LOD1:16x16, LOD2:8x8, LOD3:4x4, LOD4:2x2, LOD5:1x1, LOD6:1x1.
From the moment we call 'glTexImage2D' on LOD6, all behavior gets basically unexpected. We got garbage data in either LOD6 or LODs 1-5. Depends on driver, dimensions 1D/2D/3D and order we call it 0->6 or 6->0.

Start with the GL 4.6 specification, especially §8.14.3 on mipmapping, and review the stated glTexImage2D example with LOD6 duplicated at 1x1. Compare the expected behavior of glTexImage, glCopyImageSubData, and glGetTexImage; done means documenting the defined behavior for inconsistent mutable LOD sets.

Written by the indexing model from the issue text.