I personally think you're being a mite paranoid, not to mention showing some prejudice, over this. I wouldn't try to defend COM as an architecture - it's ghastly - but COM itself has nothing in it that prevents portability. It just uses standard C/C++ constructs, and as such can be implemented on any platform. This kind of approach only serves to weaken your argument. That aside, you seem to be missing the documentation for D3D11_RTV_DIMENSION, D3D11_SRV_DIMENSION, etc, which is the crucial part that implements the cast.

in d3d you create render target view by specifying texture and region in this texture, i.e. face for a cube texture, a slice for a 3d texture and array texture, etc. then bind the view as render target.
in opengl you do all this at once - the command with which you bind the color/depth/stencil buffer also takes parameters that specify which face, which slice, etc.
how is the opengl's direct way worse than the views?
in d3d you have additional objects to work with, which is more code, more opportunities for bugs (like leaks if you forget to release them), etc. for no benefit over opengl. don't you agree?

I'm not commenting on whether the implementation is good or bad, just on what appears to have been the thought processes behind it. Personally I can see the utility of views in D3D, from the perspective of D3D's own capabilities, but feel that the current implementation of them is a lot clunkier than it should have been. But that clunkiness does not take away from the utility, and nor does the utility of a D3D-specific implementation of something mean that GL should implement the same thing in the same way (or vice-versa, of course).

I was not arguing that their views are a bad implementation, but that they are useless in principle
Anyway there is really no point to argue over this, doesn't matter.
I only hope the GL design guys wont take example from microsoft how to do it, should they wish to add such feature in the GL.

It seems they actually added this functionality in 4.3. They did it in somewhat more complex way than what I was hoping, but it's still better than microsoft. At least we don't have new kind of objects.

I would rather have them called "texture aliases" than "texture views". that would be more correct as thats what they actually are. also would be less copycating-of-dumb-microsoft-terms. Oh well.

I would rather have them called "texture aliases" than "texture views".

Well, there not really aliases. Yes, they can be called so if you only change the interpreted internal format, however you can also select a subrange of mip levels and layers thus you actually select a subset of the texture images inside the texture. This way the "view" term is more appropriate.

Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
Technical Blog: http://www.rastergrid.com/blog/

A "view of a texture" would imply that it is NOT a texture itself but something different that references a texture (as in d3d).

But the new objects we have are really textures on their own right - after you create one, you use it exactly as you would a normal texture.

They are just textures whose storage memory aliases that of another texture.

As for that you can specify mipmap subrange - so what?
Where in the definition of the programming term "alias" it is stated that it should exactly coincide with the other object?
They can only partially overlap

Moreover the mip range for the "view" makes much less sense - why a "view" should have it's own mip range if it is just a "view" to another texture?
When someone "looks" at a texture, he sees a texture with 5 mips. But when someone else "looks" at the same texture at the same time, he sees 3 mips!

Maybe the better way to look at is that the new texture call says this texture uses the exact same backing store of memory as an existing texture. Since that is what it is doing. By being a texture in it's own right, it makes it heck-a-simple to specify all the texture state, swizzles varying, mip map ranges, lod biases, etc.. blah, blah blah. I think that which was added was great.. to me it makes crystal clear sense: "new texture's texel data references same memory for the texel data as an existing texture".

Moreover the mip range for the "view" makes much less sense - why a "view" should have it's own mip range if it is just a "view" to another texture?

Actually, it makes a lot of sense. There is the object (the texture's storage), and there are views of it. A view of an object can theoretically see less of the object than actually exists, if something is in the way. It sees some of the object, but not all of it.

Thus, a texture view can see less of the texture than the original texture does.