I see your point of view, and I agree that in the right programmer's hands, it's fine. Unfortunately, as we've seen repeatedly, people over estimate their pointer abilities and it leads to all sorts of memory and security issues.
I figure the C++ smart pointers should be as easy to use as possible, without caveats vs. C style pointers or whatever.
Maybe that isn't practical in the C++ language design right now, but that's just how I see it.
For almost all use cases, the issues mentioned don't even come up. You create a unique_ptr with std::make_unique, or a shared_ptr with std::make_shared. It lives its entire life as that type, and when you no longer need it, you forget about it.
The issues in the article had me banging my head, because they aren't how smart pointers are used in practice. The only time that you would call release(), for example, is when you are passing a pointer into a pre-C++11 API. Once you have done so, you wouldn't be worrying about calling delete anyways, because you have transferred ownership.
If programmers can't be diligent enough to learn simple unique pointers, they won't bother being diligent about any of their code.
So you may design a better pointer for them (if possible) and still have a huge spaghetti ugly bug-ridden insecure unmaintainable codebase... But at least the pointers are easy!
Even of you make them program in a rubber room helmet language, they are going to cause just as many problems.
Tools like unique_ptr are meant to let the good programmers work more expressively and make fewer mistakes. They aren't meant to let random folks write perfect code without thinking and learning first.
I figure the C++ smart pointers should be as easy to use as possible, without caveats vs. C style pointers or whatever.
Maybe that isn't practical in the C++ language design right now, but that's just how I see it.
cheers