From a security perspective, what you’re building is similar to a “bastion host”. This pair of bastions (VM+win10 host the VM is running in) is protecting both your winxp/2000 machines and your corp network/win10 machines.
Your idea to do it with VMs could work technically, but it’s super complex in a way. It presumes there’s a way to share files between a VM and host, which exposes you to an attack vector.
Further, you can assume whoever has root on win10 absolutely owns your winxp/win2000 machines (sooner or later) and the attack vector will be through your precious IT managed win10 programmer boxes that humans use to do work / read email / communicate on teams, etc…
Next evolution of the idea:
use a pair of bastions. One in front of your winxp/win2000 boxes, one in front of your win10 network. And agree on a protocol how they can share data.
If you make win10 be a host with a file share , how will your Linux box access those files - and vice versa.
To read (or list or write, or have other access in general) files from a Windows share managed by active directory, the samba client needs a kerberos principal that can be used to get tickets from the AD controller.
In principle this is easy peasy, but I doubt your IT dept is knowledgeable enough.
If you host a Samba share on your industrial bastion, all you need is to open port 445 and allow any user coming from the win10 bastion to write to it unauthenticated - you trust the network. The workflow there would be to have a robocopy cron running on win10 host to copy files from win10 share to Linux share.
Your IT dept might be ok with this, I wouldn’t be. Majority of windows attacks have historically involved scheduled tasks on Windows - it’s a very useful widget.
Secondly, you’re making a read/write dumping ground on your Linux box that can go unaudited to your Windows XP/2000 boxes … Bad idea.
Next evolution: two hosts, on your Linux / industrial host, split the win10 writable section of the filesystem from a filesystem that winxp/win2000 boxes manage.
This is better, because you can nuke any file that’s not valid gcode from the share before any of the winxp/win2000 hosts are exposed to it.
It means win10 is exposed to potentially rogue samba host.
Next evolution: find a protocol win10 IT department might be happy with to allow the win10 to use to copy files out.
Industry standard is sftp/ftps (it’s how most banks exchange files, they call them “ftp drops”, they stick encrypted zip files in there and then email each other passwords). You’ll need software to periodically copy win10 gcode to winxp/2000/Linux bastion.
Next idea: run an sftp drop over an LTE stick / internet if need be, and have individuals from your programming dept upload files directly - avoiding any festering win10 file shares that are much harder to setup as write only drop off points.
Does your programming dept have access to the internet? If yes, this is probably what you should do. Let them log in through individual public keys.
Next evolution: put the public key on the win10 file share host and have it copy things over to your drop off.
At this point we’re spinning in circles.
final evolution
Make an SFTP drop on Linux, and let 1 IT managed windows 10 account/machine/user with access to a network share somewhere (can be anywhere on your network), upload files to the SFTP drop, it can be a VM instead of a physical host if they’re comfortable giving you RDP access, no physical hardware needed. It just needs access to the drop, not the rest of internet, and needs to run winscp to your SFTP drop, that’s it. They can monitor and do whatever with it. No physical hardware needed there.
Your Linux host can prune the sftp drop and only ingest valid looking gcode into a samba share for your industrial winxp/win2000 machines. That’s not your IT dept problem it responsibility, same as winxp/2000 machines aren’t. It doesn’t need access to any of your IT managed infrastructure, one machine on your IT managed infrastructure needs access to it, and they can monitor the hell out of that machine.
Hardware wise, any machine would do for your Linux box, it doesn’t need to sit on a shop floor but should probably be on the same VLAN, or be accessible by your winxp/win2000 boxes; it does need two network interfaces at least, but that’s up to you. It should have internet access (doesn’t need to be accessible), because you’ll need to pull updates once in a while, and there should be ssh access to it exposed from your corporate network for SFTP as well as you yourself to be able to manage it. But needs nothing else. You could even forbid it internet access and feed it updates through ssh while logged in.