Damien Neil

As a high-level point, the purpose of the `protojson` package is to convert to/from the [canonical protobuf JSON encoding](https://developers.google.com/protocol-buffers/docs/proto3#json). It is not intended to innovate on the JSON encoding used:...

Regardless of the question of protobuf semantics, the design philosophy of the generated protobuf API is to provide a consistent representation of each protobuf language concept. Supporting multiple representations of...

The general idea seems reasonable. I'm not sure what the right API is. My first thought is that the best approach is one which allows easily transforming arbitrary message types...

I think you're right and it would need to be an option to `protocmp.Transform()`, although @dsnet might know of an alternative approach that I'm not seeing.

I think it's reasonable to say that `protodesc` should accept any valid descriptors, including ones where `MessageOptions.message_set_wire_format` is set. It doesn't need to do anything with the value aside from...

Since these are just constants, it would be possible to generate both Type_VALUE and VALUE for backwards compatibility at the cost of somewhat more confusing generated output.

A forced choice between one or the other makes migration difficult. Having the option to use both during a transitional period would make it more practical to change from one...

We don't need type aliases in this case; the existing code is something like: ```go type TypeName int32 const ( TypeName_ONE TypeName = 1 TypeName_TWO TypeName = 2 ) ```...

When one `.proto` file imports another, the code generator needs to know the Go package associated with each file. For example, consider: ```proto // a.proto syntax = "proto3"; import "b.proto";...

I'd want to think about it, but `Mdir=prefix` sounds reasonable. I definitely feel the pain of trying to use the `M` flag manually. It's really only practical if you've got...