For better or worse, Perl 5 is not going to be losing its refcounted implementation any time soon. The now-defunct Ponie project was an attempt to replace perl's memory management with Parrot's PMCs. While I have no doubts about the skills and competence of the programmers who attempted this heroic feat, it didn't work out as planned.

You can't rip out the guts of a mature code base and replace it with something else and expect everything to work. For instance, the internal layouts of SVs, AVs, HVs and the like have all recently received extensive changes to reduce their memory footprints (while keeping the public interface unchanged).

This work was completed months ago, and yet CPAN modules continue to surface that no longer work with blead, since they apparently have very definite ideas about what the bodies of these things should look like. And all things considered this is a minor issue compared to replacing the memory management infrastructure.

Still, if you are serious about this idea, you should think about an approach that allows this allocator to co-exist with the current system, for instance, asking for a large slab of memory from the underlying system and letting Hoard play with that (assuming you can prevent it from being unexpectedly realloc'ed).

You could then build a custom allocation framework for new code that knows about it and wants to use it. If you want to create this, go ahead. If you get stuck, ask on perl5-porters, and people will help you. I would hate you to have the impression that just because you think it's a good idea that someone else will write the code.