Windows 10 ignoring routing table

I have a Windows 10 PC that has 2 network interfaces. One of those interfaces goes into the main LAN where the fileserver, dns and the router for the internet are located. The second interface is a tiny LAN which has an PLC and an HMI. They both are physically in the same LAN but on different subnets (sorry, can't change that, outside my control).

So I have two physical interfaces and one logical one: eth0: DHCP, 172.16.x.y, MASK 255.255.255.0, default gw 172.16.x.z eth1: static 192.168.1.158, MASK 255.255.255.0 static 192.168.19.158, MASK 255.255.255.0

The HMI is reachable under 192.168.19.135

Now when I reboot the HMI I start a ping to see when it is reachable again. This should happen after about 30s. But I only get a positive ping reply after 80-90s.

Ping wird ausgeführt für 192.168.19.135 mit 32 Bytes Daten:
Antwort von 192.168.19.158: Zielhost nicht erreichbar.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

(sorry for the german text, but I think is should still be clear what we see here) I get another response for the first ping than for the second one.

It seems, that Windows after XP started to do some "routing magic" and just send data out de default route if it can't reach the target on a more specific route. It seems that other also have had this problem

I found some "solutions" that are not real solutions for me (more on that below)

1. So ping has a nice "-S" parameter to define the source address. And yes, this "solves" the problem. I get a reply instantly if the HMI is up. But I'm using that command in a powershell-script and the source-parameter to "test-connection" has a completely different meaning. And since I use this in a script this fails as soon as the local IP changes.
2. I configured eth0 statically instead of by DHCP and did not define a default route. This also "solved" the problem (i think you can imagine why this is not really a solution)
3. I've only theoretically explored this but I could install a linux based router with 3 interfaces between the PC, the LAN and the isolated LAN with the PLC and the HMI and let it do all the routing (this would for sure solve the issue! But honestly, do I need an additional computer just to work around broken windows routing?)
4. ´arp -d *´ seems to help too, but need elevated privileges

I've tried adding static routes with different parameters and metrices. No change! Adding the MAC of the HMI statically doesn't help since this MAC can change.

So my questions are:

1. is there any documentation on this change of behviour in windows?
2. is there a way to force windows to use the defined interface

So, after not finding an easy solution I decided to programm my way around the issue microsoft has created by badly messing up routing on windows.

I'm nur using classic ping with the parameter -S instead of the cmdlet test-connection in powershell

the ping-part of my code now looks like this:

$localIPs = (Get-NetIPConfiguration -InterfaceAlias "PLC").IPv4Address.IPAddress

# because this command returns a string, when the interface has a single IP-address but an array of strings if the interface has more than one address, we need to check for this
if ($localIPs.GetType().Name -eq "string") { # only a single IP
  $localIP = $localIPs
}
else { # more than one IP
  $localIP = $localIPs[0] # since it seems that windows does use the ip address as a synonym for the interface, it's not important which of the addresses of that interface we use. So we're just picking the first one
}

$pingcount = 180

do {
  ping $HMI4IP -n 1 -w 1000 -S $localIP | Out-Null # redirect the output of ping to /dev/null
  $pingreply = $?
  $pingcount = $pingcount - 1
}
until ($pingcount -eq '0' -or $pingreply)
if ($pingreply) {
  # code here
}
else {
  exit 1337 # return with an error code, we've not reached our target
}

For this I just need to make sure that the interface where the PLC and the HMI are connected is named "PLC". Than I get the address as a string or an array of addresses (depending on if the interface has one or more addresses) which I have to handle (welcome to dynamic typing...). Than it's as easy as feeding this data to ping (because Test-Connection tries to be too smart for it's own good). In $? I get true of the last command returned a success and false if it was a fail. So that's easy to handle from there on.

As far as I can see there is no documentation by Microsoft of this behaviour and how to handle it, which I think is quite sad.