Another article on the author's site references a different complaint about QML, that it sometimes does assume ownership of objects, if they are normal QObjects without parents. This led to them getting reclaimed by the window being closed. There is, of course, documentation for when this might happen.
One thing that's generally true in C++ is that the user of a library has to play along. If the library wants to allocate your objects, let it. If it wants to take ownership of your objects, expect it. If it doesn't take ownership, you need to understand their lifetimes. It's definitely one of the frustrating things about C++, but I wouldn't expect a lot of complaints about one library or another unless they were being surprisingly capricious, taking ownership on Wednesday, not using your allocated objects on Friday, copying on Monday.
The most relevant line is this: "to most other languages you are simply passing the address of a buffer". That's true! And so for the love of all that's holy, don't transfer ownership. Simply pass a (non-owning, defined-lifetime) pointer to your data to the relevant dependency.
Have asynchronous issues? Need to extend lifetime sometimes? Well, yeah, unique_ptr is not going to help you there. It's not magic.
If you got a low-level pointer out of the smart pointer container in order to pass to a foreign library, then you're not strictly using smart pointers. You violated the encapsulation in order to get a "dumb" pointer out, and the issue is related to that.
This is a complete strawman.
"Don't use a garbage collected, managed languages, they are a myth. Why? Because a pointer to some garbage-collected object ends up in foreign libraries written in C, which can hang on to it past reclamation ..."
Well, gee whiz, you will just have to learn about the exact sharing situation with the foreign code (how long does it retain the object) and do what is necessary.
> Make them raw pointers and delete them when you know it is safe.
That's completely stupid. If you know when it's safe, it means you must know when the third party library is no longer using them. If you know that, you work that knowledge into the smart pointer solution.
Smart pointers, by themselves, have their own idea of when it is safe to delete something. That idea is very clear and obvious. If it doesn't match the reality of what is safe when, then you have to augment the logic. That's it.
If a foreign library directly accesses an object that you track with a smart pointer, you can create a proxy object representing that library, and that proxy object can hold on to a smart pointer on behalf of the foreign library.
The complexity of dealing with the foreign library could be entirely minor (and self-contained) compared to the overall resource management problem of that smart pointer class; you could be making a lot of unnecessary work for yourself (and future bugs) by uprooting the smart pointers in favor of dumb pointers.
What are you going to do if part of the reason the smart pointers are there is that they are providing needed exception safety?