I'm not sure the Moose developers want to be in the business of maintaining forks

I think it only becomes a problem if you term it "forks"!

Often as not, when you utilise subs from modules written by others, you end up writing your code around their interfaces. Adding glue code and coercions to take your data into and out of the forms required by the subs you utilise. And that has to either be done at each site you call those routines, or you wrap their sub in your own and do the coercions once there.

Once you've wrapped their subs into your own wrappers, it's not a big step to lift their implementation into your wrapper to avoid or simplify the coercions required.

From the sounds of things above, it looks like the Moose developers are already moving to replace some of their dependencies with XS code to improve their performance. Does that count as "forking"?

Rolling up their dependencies into a support package, thereby isolating themselves from divergent development by myriad authors, could be a good first step on that road. As it would allow them to establish a dependency-free test-suite as a baseline for ensuring their XS conversions don't introduce bugs. It would also provide a pure-Perl fall-back position.

One could even see the possibility of enlisting the help of the dependency authors in building and maintaining the individual parts of the Utils package. Enlisting their help and expertise in getting the "extractions" tailored to Moose requirements and maintaining them in line with developments in the dependency packages. That kind of cross-collaboration seems to be right in line with the aspirations of OSS.

Still, I'm just floating ideas--with no expectation of anyone picking them up.