Re^2: Is it ever legitimate to override $^O ?

[syphilis]

The problem here is very similar to what you report for 'make test'

Yes - that's the issue.
On MS Windows, be it Windows 7 & mingw-built perl-5.34.0 (as in my case), or Windows 10 & MSVC-built (as in the testers matrix), the overriding of $^O generates that error.

The line numbers are different: 71 (here) vs. 76 (yours) — I don't know if that's significant.

In earlier attempts to work out what was going on, I had inserted some debug statements into Entity.pm.
I then commented out those statements - thereby leaving the code in its original state, but altering the line numbers.
So it's not significant, and I'm sorry for the confusion.
I believe it's only Windows that's being affected by this.

The distribution provides both a Makefile.PL and a Build.PL. The INSTALL file only references perl Build.PL followed by various ./Build commands (no make anywhere). I had a look at a few reports, all had ./Build test — again, I don't know if that's significant.

I don't think there's anything significant in that.
It makes no difference whether the module is built using Module::Build or ExtUtils::MakeMaker. The behaviour is still the same.
If cpan/cpanm/cpanp is invoked to do the building, then I think M::B will be used.
When I build manually from source, I use EU::MM as that's my preference.

Because Strawberry Perl have not yet released a perl later than 5.32.1, there aren't many Windows perls in the wild that are at version 5.34 or later.
I build my own perls and test them regularly, but I haven't been testing their capabilities to build Path::Class because that module has never interested me.
Having recently become aware of this problem, I'm unsure as to where it should be reported.
Maybe I should just open a perl Issue and ask there - but I wanted to first draw on any wisdom that exists here.

Cheers,
Rob