Don't prematurely tie your design to poor decisions just because "you can see yourself" needing something - aka. the YAGNI principle. If you know you need it, design for it. If you don't 100% need it right now, don't worry about it.

...

GetType() is a code smell.

Those were just examples. Shaders are a better example of a resource that has common functionality (set resources, constant buffers) and that are further derived into specific types representing their stage. (example: IDeviceChild -> IResource -> IShader -> IVertexShader)

You seem overly inflexible regarding OO principles, which I understand, but again, given the narrow scope of the library I think (and I believe many others do) sacrificing some principles in exchange for an easier/lighter API has more benefits than not doing so.

I don't think we can say D3D API is a bad API because it implements GetType() on it's resources, or because it has an interface hierarchy. Every problem you point to ends up only being relevant to the implementation details, which is why I'm being so "stubborn" with my interface design, which apparently isn't all that bad, we just can't find a way to properly implement it.

I'll probably have to abandon the design for an apparent lack of tools in C++ to properly implement it. A simple way to implement a virtual method by creating an alias to another base method (effectively hinting the compiler to reuse the vtable pointer) would solve the extra indirection introduced in my previous example...

BTW reference counting can be done easily without inheritance - see std::shared_ptr for a classic example. Intrusive versions are also trivial to design and implement using compile-time template solutions.

I know, I'm doing that right now actually. However I'm not convinced it's a good way to go. The more I go with it the more I think I should abbandon that idea and have a reference counting object as the base class, and just provide a helper template function to handle automatic AddRef/Release. Anyway, that's a minor problem I can analyse later.