Dan Burkert

The language guide says that map fields are treated as repeated key/value message types, so I believe `prost` is at least _not wrong_ to be making this optimization. Have you...

The map encoding code goes [way out of it's way to do this optimization](https://github.com/danburkert/prost/blob/master/src/encoding.rs#L746-L811), so at some point in the past I decided this was an important optimization, although I...

FWIW I'm still not convinced `prost` should be doing this optimization. It makes the code a bit uglier, and if it causes compat issues then I think we should consider...

I looked into what it would look like to change the behavior so that map keys are always encoded. It ends up making some of the most complicated code in...

> A guess as to why you could have thought of this optimization (or whatever you'd like to call it) as important: Because of Prost's way to represent messages as...

> This seems like a pretty easy change, but it's definitely a breaking one and I'm not sure how making breaking changes like that should work with prost. Is an...

revisiting this while triaging issues. Perhaps `prost-build` could be a bit smarter here and automatically recognize when it's generating a submodle, that a 'top-level' module with that name already exists,...

> For example, if the Go or C++ implementation had this behavior, it might be considered a bug? To be clear I definitely agree that this is a bug in...

What do you expect `prost` to do here, beyond what's outlined in #2? Is the idea that unknown fields should fail the decoding? That's a non-starter, it would hamper forwards...

> wouldn't address the more subtle cases What cases?