One part of the problem is that Rosetta can only run x64 code, it can’t run x86. A lot of Windows is still x86.
The only solution at the moment is to run Windows on ARM in a virtual machine (Parallels) on the Mac. And then, it will only runly ARM64 code, not ARM32 code, so some Windows ARM software won’t work on the M1 Mac even then (Apple has explicitly built the ARM32 compatibility out of the M1, it is a pure 64-bit chip, it won’t even run ARM32 iOS apps). Apple has started their ARM game as far forward as possible, to not fall into the Intel/AMD trap(1), at least not for the next 10 years or so.
Somebody could certainly write an x86 emulator, but why bother? Microsoft will be more interested in selling you a Windows in the Cloud VM than providing any support for Windows to run like a comparative sloth under emulation on the M1. Just look back to the PowerPC days of Apple, although PowerPC at the time was faster than Intel, the x86 emulator, VirtualPC, was an absolute dog. Likewise, later, when PowerPC had lost its speed advantage to Intel, the original Rosetta emulated PowerPC code on Intel, because the Intel chips were much faster than the PowerPC chips, Rosetta software was a bit laggy, but just about usable.
Emulating x86 and x64 and running a second OS under that emulation is going to make it slow, in comparison to running it on a Windows PC or using the native equivalent on the Mac. Maybe with one of the following generations, the Apple Silicon could possibly do it at a reasonable speed, but the AMD and Intel chips are also advancing, so it is always a game of diminishing returns. But the question is: why bother? Native software will always be faster, by orders of magnitude. For the price of the emulation software(2), you could probably get a half-way decent Windows PC to run that old software. Use RDP, TeamViewer or something and you can even control it from the Mac.
Rosetta 2 translates the x64 code on first-run into ARM64 code, it doesn’t emulate it. That isn’t as good or as reliable as compiling the source into ARM64 to start with, but it is better than nothing. But you can’t really do that with a virtual machine, especially one that is running 32-bit code, as well as 64-bit code.
It isn’t impossible to do, but it requires so much effort that it probably just isn’t worth it. Qemu is probably the nearest thing there is, but it isn’t a full blown VM experience and its performance and stability will be questionable, at least in the beginning - don’t get me wrong, they have done some sterling work getting older processors running under emulation on x64 and ARM platforms, but those were older, slower processors, so even in emulation they still scream. They were also comparatively simple architectures, compared to ARM or x64. Maybe in a couple of generations, x86/x64 emulation on Apple Silicon will be up to the levels of 2016 Intel native performance, but Intel and AMD have moved a long way forward from there already.
(1) The Intel processors, and by association, the AMD processors, have to have backwards compatibility to run old x86 code, going right back to MS-DOS. That means there is a lot of “wasted” space on the x64 processors, because they have to cope with the old x86 instruction and even 16-bit memory segmentation. If Intel and AMD dropped all that crud from their processors, they’d be a lot smaller and/or they could include more cores or use more efficient design that would save energy. Apple has avoided this trap and thrown out everything historical. They are starting with a more-or-less clean slate.
(2) The virtual machine software, with chip emulation will become ever more expensive, because it is moving into niche territory. Normal virtual machine software is fairly light weight and uses key features of the underlying processor to provide the virtualisation - the so called Hypervisor. The VM producer can concentrate on making the VM compatible with key operating systems and providing basic drivers for keyboard, mouse, network and video. If they suddenly have to invest thousands of man-hours to write in processor emulation and get it 100% accurate (otherwise it will constantly crash the client VM) will make the VM software too expensive.