Even if certain Windows-specific modules were added to the core _today_, these fixes would still need to be done to deal with older installed Perl versions.

Ive said it a lot of times Adam, a lot of these fixes can't be done without proper access to the Win32 API. And as long as that API is reachable only through a non core module set the issues involved with adding better support become much more difficult. You can't just say "am I on Win32? Yes ok, better use the Win32 tools" you have to say "am I on Win32 AND do i have the required modules available". Which complicates things and means that less Win32 folk are going to bother to try to add proper Win32 support to core modules.

Not only that, but look at the mantra of P5P, it basically says "fix what you like, but you can't use non-core modules to do it". Which means for instance that functionality in EU-I simply cant be used or tested under a core build. (Although what I find really amusing is that you can added Win32 API support to core modules, but only via XS, for some reason providing that access through a perl layer is verbotem. So we have Win32API calls for specialized purposes scattered throughout the core, but always hidden so that end users can't make use of them in interesting new ways. Which is bad because it raises the skills requirement for improving Win32 perl, not only do you need to be conversant with the API, you need to be a good perl programmer, and a good C/XS programmer.)

As an example using core perl there is only one sharing mode that you can open a file with, using Win32API::File there are a variety, including the mode that Windows itself uses to lock DLL's but still allow them to be renamed. (Annoyingly the default open mode for Cygwin is different from the default open mode of native builds. This is why you can delete files opened with Cygwin perl, but not AS perl)

Similarly since Win32API::File is omitted from Core it is unsurprising to me that File::Temp uses broken *NIX based logic to do its thing on Win32. Wheras if Win32API::File were included in core then the author of F::T (apparently not a win32 developer) might have looked at the documentation for Win32API::File and found out that Windows supports an OS level temporary file which will be autodeleted once all filehandles to it are closed. Or with even better API support he might have found the API call that windows provides to produce a guaranteed unique temporary file.

But since this stuff isn't available to Core, and since non Win32 developers seem to have this strange aversion to using MSDN library search, (maybe because they know that since there is no support for such in core there isnt any point in searching) the fact is that non-win32 programmers will never even know that there are better ways to do things on Win32.

So I stick to my guns: adding proper win32 API support to core is not a nice to have, its an essential part of improving Perl support on Win32. And doing it in blead even will be a signal to the community that the investment in making the code work better on Win32 will not be a wasted one.

And as a closing thought consider this: In VB you can bind to a Win32 API call with one line of code. In Perl you cant bind to API at all out of the box. That VB can provide better OS access than Perl does is just wrong.