I'm not familiar with the history about p5p's previous views and actions (or inaction) related to this topic, so I'll refrain from comments on that aspect of your post.

Since I primarily work in Windows, the idea of getting Perl to work better in Windows is appealing. I especially like the idea of having Perl default to the filesystem API that supports the longer path lengths and Unicode. However, I don't have the expertise or time to help with efforts to achieve that goal.

My concern about your idea is proposing the use of Win32::Unicode. When I was trying to work with long paths in Windows, I had issues getting Win32::Unicode to work. It's been quite a while ago, so I don't remember what in particular I had problems with. Ignoring that, the latest version was released back in 2012. That by itself might not be an issue. But it becomes an issue when there a lot of failures in on CPAN Testers for newer versions of Perl and the author hasn't really responded to submitted issues. The combination of all of those facts leaves an impression that the module is broken and abandoned - at least that's the impression that I personally have.

I think a better candidate might be Win32::LongPath, whose author does credit the author of the Win32::Unicode. It has a much better success record for newer versions of Perl on CPAN Testers, has no currently open issues and the latest release was about 2 weeks ago.

I'm not going to try pressure anyone to not use Win32::Unicode. But I thought I'd share my thoughts that Win32::LongPath would be a better choice along with the reasons why I prefer Win32::LongPath over Win32::Unicode.