Part of the problem is that you are messing with the refcounts of the proxy object, not the actual shared object which you do not have access to.

Shared data is implemented such that the actual storage used lives in an interpreter space that is inaccessible from Perl.

The variables that you declare 'shared; in your code, are proxies -- place-holders -- for use by your threads to gain access to the actual data via attached magic.

When one thread dies, any proxies it holds to a share variable are destroyed, but the actual shared data may not be, if some other thread still holds a reference to it.

That is, the refcounts on the inaccessible shared data have to count all references from all threads. When the reference count on a proxy in one thread drops to zero, that proxy is destroyed, and refcount of the actual data is decremented, but may not reach zero at the same time if some other continuing thread has a reference to it.

The upshot is, that messing with the refcounts of shared things is probably a bad idea and almost certainly isn't achieving whatever you set out to achieve by doing it.

Originally, and until relatively recently, it wasn't possible to share blessed things. I think for very good reasons.

Unfortunately, it doesn't look like the implementation that added the ability to shared blessed objects was properly thought through.

(Personally, I advise against sharing objects between threads -- it is (IMO) entirely the wrong approach to the problem; where required, threading should occur within objects -- but if you do use shared objects, messing with their refcounts is just asking for trouble.)

One thing that does look like a real bug -- rather than just an odd corner you should never go into -- is the weirdness of a second call to Devel::Refcount preventing the destruction of the object. That looks very iffy to me.