Thanks for the feedback! All of these suggestions sound useful, but I think they are out of scope for this proposal.
For line numbers and other context information, we would have to include more information in DecodingError.Context and friends.
I believe we could add fields without ABI problems (can someone please confirm?), but the issue is that the change would have to be made concurrently in two libraries: We'd have to change the stdlib, where the error types live, in order to add the fields; and we'd have to change Foundation, where the encoders/decoders live, in order to populate those fields when constructing the error. Orchestrating such cross-project changes is very challenging for those of us outside Apple.
Perhaps there could be a path forward where we add things iteratively, maybe adding optional properties to Context first, and then populating them in a subsequent PR to Foundation. However, I think that would leave us with some unfortunate baggage, where fields are optional that wouldn't need to be if we could land everything together.
One more issue here could be that the Foundation encoders/decoders deal with Data, not files, so they might be able to know the line number, but they won't know the file name.
Using the path to locate and highlight the source of the error is something that can already be done using the information in DecodingError.Context.codingPath and friends. I demonstrated one such use in the library I built to explore some options here. But in terms of the formatted path in the output of debugDescription, this proposal makes no guarantees about the specific format. It only suggests possible formatting changes to make error printouts more readable and approachable. In general, we should not rely on the output of debugDescription for parsing/highlighting/etc, and should instead inspect the underlying values directly.
I covered something like this in the “Print context of surrounding lines in source data” portion of the proposal. Are you suggesting that we point more specifically, like how compiler errors draw ASCII art arrows to point to a line/column? I'm all for it, but since this is just a sketch of future directions, I'm not sure we need to go into that much detail here.
If you haven't seen The future of serialization & deserialization APIs, a thread where folks are discussing future iterations of serialization in Swift, I encourage you to check it out. I think there's a real opportunity to shape the error output to be as nice possible from the beginning!