Modifying Decoder with a new extension point is not in scope for this proposal; we need to stay focused on formatting the information we have available. But I do think that sounds handy and is probably a good idea to bring up in the design of future Swift serialization tools or a later proposal.
I’m curious if you can say more about specifically what you’d be looking for in an output format? If we could customize the path per serialization format, there are obvious advantages to being able to generate a path that is compatible with tools such as jq. But given that we are currently providing an output format that is serialization-format-agnostic, what advantages do you see to using any one particular syntax? You can always built your own helper functions to format errors in ways that work with jq, plutil, etc. I think, for this proposal, we’re looking for something that’s readable and potentially useful in a Swift context, but it can’t make guarantees about the specific format. That said, I’m not opposed to making small tweaks if it doesn’t hurt readability and it provides a useful shortcut for a common use case.