Nested Elm JSON decoder failures report missing fields without full path context

When decoding deeply nested JSON payloads with Elm 0.19's core Json.Decode module, result-based error messages for missing fields can be difficult to map back to the exact location in the source data. The compiler guarantees no runtime exceptions from well-typed decoders, and the module provides built-in error reporting for malformed JSON, but the diagnostic output for a missing key inside a nested record or array may not always preserve the complete traversal path.

This uncertainty matters when building decoders for large API responses where a single absent field among many nested objects causes a generic failure. The goal is to determine whether the standard library's error reporting is sufficient to pinpoint the missing key, or whether additional decoder composition is required to retain path context.

Does core Json.Decode in Elm 0.19 include the full field path in error messages for failures inside nested andThen or map combinators? Is there a documented difference in diagnostic detail between Json.Decode.at, Json.Decode.index, and manual field extraction when a key is absent? What is the recommended approach for maintaining no-runtime-exception guarantees while improving error specificity for missing fields in complex payloads?