Can you post your DXDIAG too please.
I'll post my answer when I stop swearing at losing my 20 minute post to the back button on my mouse.
First let me say that textures in the matrix are made of layers. For example let's use white dada shoes with coloured stripes:
magenta magenta - no hyperspeed blur
magenta - hyperspeed blur
indigo
indigo - hyperspeed blur
As you can see when there is a hyperspeed blur the colour overlay for the shoe texture is revealed. This tells us that the base shoe texture is the same and the colour is an overlay (the colour mask breaks with the transparency introduced by the hyperspeed blur)
Now: How 3D surfaces are lit. Without getting into too much detail, 3D models in games are made up of triangles (there's a very good maths reason for this). Every triangle has a front and a back. Most of the time the back never gets drawn to save on processing power (Ever placed the camera inside your RSI? Notice how most of it is invisible from the inside? The triangles aren't being drawn on the back) To light a triangle there is a thing called the Normal. It is an imaginary line that sticks straight out of the middle of the front side, so if the triangle was flat with the front facing up the Normal points straight up. Lighting uses the normal. If the normal points directly towards the light source then the front side gets maximum light and the back is in the shade, and vice versa. If the normal is at an angle to the light source then the angle difference is used to calculate the percentage of the light the side gets.
Now you say that MOST things light correctly but some do not... in fact they seem to be lit as though the light is coming from the opposite direction. What causes this is the normal pointing out of the back of the triangle instead of the front.
BUT... if that was the case then all the hair in the game would light wrong for you as the models are shared and only use different textures. What I believe is happeneing is that the colour overlay for the hair that is lighting wrong is backwards or the layers are in the wrong order. The layers should be stacked so that the front of the base texture is against the back of the colour overlay (like a photoshop image with layers).
The textures that have the problem probably have the colour overlay drawing backwards (front meets front) so the light on the colour overlay is the opposite of what it should be.
Under directX 9 the overlay gets ignored (because it is transparent) and the lighting is calulated on the base texture... under DirectX 10 the overlay is what gets the lighting (well that's what appears to be happening).
So the problem is with the texture or model data in game and not with Vista. The problem could also be caused by a bug in your video drivers that does things in the wrong order. If other people running Vista don't get this problem then it is the drivers. If everybody sees you the same then it is the game data.
The solution to the screen shot problem depends on how MxO saves a screen shot. If it uses a built-in procedure in DirectX then Vista is the cause. If MxO grabs the image and then saves the file then the problem is a change in DirectX 10 has broken the "grab" stage of the screenshot process. This seems likely as Vista has that swanky new Alt-Tab card flip thing which could well have changed the way DirectX drawing surfaces are referenced.
That is one for the programmers to answer as I don't have access to the game code.
Vista looks like it might be fun!
Last time I was faced with tricky (= fun to solve) problems like this was due to CR2.
BRING IT ON!
Gotta love the waiting game.
For the first 12 months of MxO I couldn't reconstruct or reenter the Loading Area without crashing thanks to my drivers... Ended up having to use a version that a French friend slapped together that patched the newwer forceware drivers onto the interface for the mobile cards... my driver version comes up as a bunch of ?s
