I just found one example of the sort of thing that scares me in threads:

    /* The code below checks that anything living on
       the tmps stack and has been cloned (so it lives in the
       ptr_table) has a refcount higher than 0

       If the refcount is 0 it means that a something on the
       stack/context was holding a reference to it and
       since we init_stacks() in perl_clone that won't get
       cleaned and we will get a leaked scalar.
       The reason it was cloned was that it lived on the
       @_ stack.

       Example of this can be found in bugreport 15837
       where calls in the parameter list end up as a temp

       One could argue that this fix should be in perl_clone
    */
      

    while (tmps_ix > 0) {
      SV* sv = (SV*)ptr_table_fetch(PL_ptr_table,     tmps_tmp[tmps_ix
+]);
      tmps_ix--;
      if (sv && SvREFCNT(sv) == 0) {
           SvREFCNT_inc(sv);
           SvREFCNT_dec(sv);
      }
    }
[download]

I do not even begin to understand the reasoning or magic that lies behind the need to serially increment and then decrement the refcount of an SV if you've just tested it and it is currently set to 0?

It's this kinda thing that has made me wary of playing with refcounts.