Well I wouldnt say these items are 'marginal', because most come from real life scenarios. You can work around things but it is always that u have to remember that there were some boundary cases with shared_ptr. It took me some time to convince my colleagues to swap from raw pointers to shared pointers and having some boundary cases doesn't help then. I still prefer shared pointers, but I am not sure if all in all they would be better than e.g. intrusive_ptr's with ref counting (even without lacking the weak_ptr feature). Note that i look upon this from a client perspective (i.e. large data acquisition application), not from a library builder perspective.
I really miss having a "lost and found" feature, which (in the late 90's) I wrote about as being one of the six essential features of my smart pointer design. That is, given a raw pointer p that is already known to the smart pointer system, creating another smart pointer from p will work in harmony with them, NOT break it. I've repeatedly come across code that hooks up objects with other objects in the constructor and I've had to work-around that in various ways, usually by adding a Create wrapper that finishes the work, and sometimes fiddling more than I would have wanted to with the design. I've also found cases where it is really annoying not knowing whether another smart pointer has already been created yet for the object. Anyway, for intrusive smart pointers, the "lost and found" feature is very easy and efficient to implement. So perhaps it should be part of Boost intrusive_ptr as an extension to the standard, or another class can be added with a different feature set. Anyway, if you want a class like that, feel free to grab my old code from the "Classics" or "Repertoire" project parked on github. —John