COM isn't changing. The entire point (the only point, actually) is interop.
So why is your language-specific wrapper changing? Well, for continued language support... but that does appear to be happening with ATL.
Call me skeptical, but we now have... let's see... four COM C++ API's to choose from, just considering the ones affiliated with MS. (If someone offered me an even bet there weren't more without looking it up, I'd take that bet).
Maybe, since the entire point is interop, we should settle on one at some point??
(1) raw C API IUnknown/BSTR/VARIANT/etc; (2) CComPtr/CComBSTR/CComVariant/etc; (3) _com_ptr_t/_bstr_t/_variant_t/etc; (4) WIL's baby COM API
I would be so happy if they ditched IDL, or at very least improved its development experience, specially with the excuse to wait for C++ reflection to give back the experience of using C++/CX with C++/WinRT, means I will probably retire before they even bother to start.
My preference is never to use _com_ptr_t et al. (instead CComPtr for a nicer RAII) since they throw exceptions, and almost none of the developers I worked with expected that, so lots of unhandled exceptions at runtime was the result.
One of the best things about the COM (previously OLE) API was actually HRESULTS, so I always encouraged their use, and IErrorInfo wherever possible.
So why is your language-specific wrapper changing? Well, for continued language support... but that does appear to be happening with ATL.
Call me skeptical, but we now have... let's see... four COM C++ API's to choose from, just considering the ones affiliated with MS. (If someone offered me an even bet there weren't more without looking it up, I'd take that bet).
Maybe, since the entire point is interop, we should settle on one at some point??
(1) raw C API IUnknown/BSTR/VARIANT/etc; (2) CComPtr/CComBSTR/CComVariant/etc; (3) _com_ptr_t/_bstr_t/_variant_t/etc; (4) WIL's baby COM API