The aim is to provide CPAN authors a Win32 Perl platform that is similar in use and style to the Unix Perls, to make it easier for them to port to Win32, and to provide a suitable basic Perl platform for experienced Perl developers that prefer to install from CPAN, instead of using binary packages.

I didn't read that as aiming for a replacement of ActivePerl. Having a sensible toolchain on Win32 would remove much of the perceived reluctance to develop on that platform, because it would be much easier to start working _right away_, without having to dig around for compilers, header files, and what not.

I'm also guessing this would benefit the AS distribution in the long run, since it would mean more modules will build on Win32, which means AS will be able to package those too.

You wrote:

I imagine that any *nix programmer that encountered this problem when trying to port their module to Win32 would probably take one look, blame it on a broken MS C compiler/CRT and understandably give up, but the problem lies within the the perl sources.

That might very well be true right now. If this project succeeds, that argument would no longer be true, since we'd be using the same tool chain on both platforms. The grant also asks for fixing bugs like these.

You wrote:

Maybe Strawberry is only the starting point and would enable/encourage more people to become actively involved in making Perl work better on Win32?

I believe that's the goal, yes, absolutely.

Even though I said goodbye to Win32 long ago (a personal and professional luxury, I know), I do see this as a valuable plan: it would improve perl for a very large user base, integrating their development practices with those of unixy platforms; making more modules available to them means an expanded user base, which means more eyeballs, which implies improved code. I feel that's a win-win situation for both camps. Having used that word, I even have hope we won't be speaking of "both camps" in the future.