According to newSVrv, it's

SV_CHECK_THINKFIRST_COW_DROP(rv);
(void)SvAMAGIC_off(rv);

if (SvTYPE(rv) >= SVt_PVMG) {
    const U32 refcnt = SvREFCNT(rv);
    SvREFCNT(rv) = 0;
    sv_clear(rv);
    SvFLAGS(rv) = 0;
    SvREFCNT(rv) = refcnt;

    sv_upgrade(rv, SVt_IV);
} else if (SvROK(rv)) {
    SvREFCNT_dec(SvRV(rv));
} else if (SvTYPE(rv) < SVt_PV && SvTYPE(rv) != SVt_IV) {
    sv_upgrade(rv, SVt_IV);
} else if (SvTYPE(rv) >= SVt_PV) {
    SvPV_free(rv);
    SvLEN_set(rv, 0);
    SvCUR_set(rv, 0);
}

SvOK_off(rv);
SvRV_set(rv, sv);
SvROK_on(rv);

SvREFCNT_inc(sv);

SvSETMAGIC(rv);
[download]

Or you could use

sv_replace(rv, newRV_inc(sv))
SvSETMAGIC(rv);
[download]

Update: Fixed ref count as per reply.

Your version of newSVrv wouldn't work. Its only 5.12 compatible, not before, because of the SV type changes and the prepare_SV_for_RV macro changed. Can RVs have a PV string pointer (flags off of course)? Does an RV always have to be of type SVt_RV (5.10) or SVt_IV (5.12) or any SV with ROK can be a reference? The sv_replace seems like the safest idea while i'm writing this.

There is a missing refcount inc on sv before "SvRV_set(rv, sv);". Also there is a macro for the old RV sv type to IV, seems to me that it will provide backwards compatibility sv.h#l75 in perl.git

Your version of newSVrv wouldn't work [before Perl 5.12]

It's not a version of newSVrv, and you're free to do the exercise yourself for 5.10.

Can RVs have a PV string pointer

Like you just said, there's no such thing as an RV anymore.

Does an RV always have to be of type SVt_IV (5.12) or any SV with ROK can be a reference?

Latter. Even before 5.12.

The sv_replace seems like the safest idea while i'm writing this.

That's quite an understatement.

There is a missing refcount inc on sv before "SvRV_set(rv, sv);".

You're saying that newSVrv causes referenced material to be destroyed permaturely. I don't believe you.