Just as the title says. My routing tables all of a sudden aren't registering the "NOT" operator and turning my trains when they aren't supposed to (using routing tables in routing switch motors).
Using Railcraft Version 9.4.0.0

It would help if you were to post one of your routing scripts.

that looks to be a wye track, are you sure that's the one you want? (cant go straight on them)

will do as soon as my game finishes launching

That script made me turn when I was supposed to go straight. My train's destination is set as "Village10"

The one containing the script pictured is the top left (switch track). When the locomotive was set to "Village10" it switched me when it should have let me go straight.

That does seem to be contrary to the expected behavior. I tested the NOT operator with a Routing Detector Block yesterday and it was working as intended.

If there is a problem, its far more likely to be the switch code that is inverting the results.

I'll test it again once my game loads. If it is still doing it, is there anything I can do to fix it?

There's pics from my test just now. The track did switch when it should have gone straight

I should point out that the script you just posted always resolves to true, no matter what the destination.

OR (implied)
NOT
Dest=Village2
NOT
Dest=Village10

Since its not possible for both Dest= conditionals to resolve to true, the implied OR statement will always resolve to true. I suspect what you really want is the following:

AND
NOT
Dest=Village2
NOT
Dest=Village10

Further testing just showed me that this problem is only happening that one destination ("Village10"). All others route properly with the 'not' operator

Probably. But I did find out that the problem is only happening with the Village10 destination

The routing table language uses a "prefix" operator format meaning that your operators go in the front and the parameter(s) of the operator go right after. If the parameter(s) happens to start with another operator then all the params of this new operator will also be a part of the first operator statement.
So...

NOT
Dest=Village2
NOT
Dest=Village10

Is the same as: (NOT(Dest=Village2)) OR (NOT(Dest=Village10))
And...

AND
NOT
Dest=Village2
NOT
Dest=Village10

Is the same as: (NOT(Dest=Village2)) AND (NOT(Dest=Village10))

Lacking any evidence that there is an actual bug here, I'm going to close this. Thank you for the report, best of luck in future projects.