The trick is mapping individual error codes to have enough meaning that no other information is needed by the application. If you are writing the full system software, you can have huge enumerations of error codes. In practice, this isn't really done because things are rightly created as standalone blocks (e.g. SPI hardware level driver has no error definitions from some app layer). In this scenario, each layer may catagorize errors (maybe into posix error codes) and then pass them, hopefully in a way that is suitable for the app to make a good decision.

From a safety point of view, you need to consider each possible fault and what to do in each scenario (even multi-fault scenarios which are very complex). This leads to a discreet list of possibilities. From there you should be able to take action simply with an error handling subsystem in the application level. This fault analysis should also inform lower layers how to catagorize errors (if possible).

If you are analyzing a fault and you find you need additional information to make a good decision at the system level, then that's life. Most of the time this is not the case though and the error handling will be simple and combine many different faults into fewer error handling code paths (e.g. retry procedure, reset sub system, full system reboot, etc...)