1. The whole of the STLSoft exception hierarchy is going to have a thorough going over with STLSoft 1.10. Whenever that is ...

OK.

...

The theoretical objection is one I've spoken of before: the lowest level abstraction should have a single error-handling paradigm, and because (i) such low-level features should support exception-free components, and (ii) failure to create a COM object is not an exceptional condition, I chose to go with HRESULTS at that level.

OK.

Although I don't do much COM at all, I am not sure (ii) is always true.
If some program assumes the existence/installation of some component every time it runs (especially if it installed it itself), then COM is conceptually treated just like a statically linked library, i.e. it should always be there. The sudden disappearance of the COM object should be an exceptional case.

3. Yes. I've seen many such schemes, and Synesis has had one for donkeys' years - called hresult - but it's just never entered the COMSTL branch. However, since you appear to want one, I may take a look at it again.

More fundamentally, I'm interested in considering whether there're other approaches to, say, the co_create_instance() issue.

Well, you could always have a different name for the throwing version... e.g. co_create_instance_throws().