I've just been having a discussion with our service people about something similar. I write software that interfaces to a number of third-party hardware devices. When I get an error code from one of these, I log it. The service people want the software to interpret the codes for them. So, for example, I get an error code that says "timeout". They want me to translate that into "check the comms cable between A and B, check the power supply at C, look at the LED at D and if it's green, replace E". And it's not even that simple, there are about a dozen other possible causes - but they're less likely.
The combinatorial aspect of it's bad enough, but you're always certain to miss possible causes. I've told them that they should have some kind of knowledge base that matches symptoms to solutions. That way, they can add to it as they find causes and solutions.
So, when your car says "fuel mixture rich", it's reporting what the sensors tell it - it's not attempting to diagnose the cause. If it was going to do that, it would need a zillion more sensors (that could all go wrong, and would raise the cost of the car). Be thankful you get the clue that you did and take it to someone who knows what their doing. Or diagnose it yourself.
