Thank you to all respondents. (I have enough trouble keeping track of just one perl instance per process ;-)
Seems that USE_MULTI and USE_IMP_SYS have to match - either both defined or both undefined.
I don't really use an unthreaded build all that much, as I like to stay in sync with the configuration used by the broad population.
But, as someone who uses neither fork() nor threads, it would probably the "right" configuration for me (if it really mattered).
Hence, I like to keep checking that the capacity to build an unthreaded perl on Windows doesn't get lost.
The first thing one finds out pretty quickly on an unthreaded Windows build, is that running
cpan Some::Module fails to succeed - and that's the case irrespective of the status of USE_IMP_SYS/USE_MULTI.
That failure occurs because the cpan utility does a fork() during the "make test" stage.
There's a bug report from 3 years ago about this at
https://rt.cpan.org/Ticket/Display.html?id=143500. Maybe that bug report should be copied onto the
github repo, though I doubt that would make much difference.
Anyway ... it's pretty simple just to run
cpan -T App::cpanminus (which skips "make test") and then use
cpanm to install modules.
For now, at least, I'll just keep building the unthreaded builds the same way that I always have (with USE_IMP_SYS and USE_MULTI undefined).
Cheers,
Rob