After spending a while looking at the changes, I actually don't understand why we need to do the field discovery through ProtobufField attributes.
Also, I don't quite see in what exact use cases is the new reflection API more powerful (that's the reason why we are making things more complex, right?)

Well, I think in many ways we're actually making things simpler - that was the aim. There's just one entry point for reflection: the descriptor, that you can fetch either via an instance of IMessage, or via the type name.

It's more powerful because given an IMessage, I can get to its MessageDescriptor where I couldn't before - I could get to its FieldAccessorTable, but that was all. (I could go from that to any field to the field descriptor to the containing type, but only if there were some fields... and that's really circuitous anyway.)

We don't have to do field discovery through attributes, but the previous approach of "here are the property names for this type" doesn't work without a FieldAccessorTable per type - there's no obvious place to put them. One option would be to change the Type[] of generated types to something more structured, which would include the properties, nested types and nested enums. Other suggestions welcomed.

Rebased to csharp-experimental. Will see how the CI builds do...

Thinking more about the field access part, I think I am happy with the accessors being separate types from the rest of the descriptors - they are about interacting with instances of messages instead of just describing the "static" state. It also means we'll be able to represent "no field access available" by returning null from the accessor properties.

I took another look.

What looks good:
-- the integration of descriptors and field accessors, and providing a way
-- the way Descriptors are exposed (as a static property + explicitly implemented property on IMessage)
-- field accessors being separate types from descriptors

What I don't like:
-- the idea of introducing field attributes that will be visible publicly just to be able to build the descriptor objects internally (along with introducing the N^2 initialization algorithm). We should definitely come up with an alternative approach.

What I haven't seen:
-- what is the expected way user will access the fields in different scenarios. My understanding is I supposed to grab the accessors using Descriptor.FindFieldByName("my_field").Accessor , Descriptor.FindFieldByNumber(25).Accessor or by iterating though Descriptor.Fields. First two feel a bit clumsy and if they are expected to be used often, we might want to consider adding some kind of shortcut ( like Descriptor.FieldAccessors view with [ ] indexer that accepts both int and string maybe).
-- it looks like for Oneofs, you only have the list of OneofDescriptors and you can't easily access a oneof by its name

Nit: please grep for IReflectedMessage occurences, I think I saw some leftovers.

I've been thinking about the attribute aspect, and I think I've worked out a better alternative. Will try that this morning.

Field access: it's not clear to me how people do typically use reflection, other than when iterating over fields (as we do in JSON, for example.) Your FieldAccessors indexer seems like a good idea though. I suggest we try to get the guts done and merged first, then we can experiment with this a little.

Oneof access by name: I can definitely add that fairly easily.

Good job on finding a workaround for the attributes! Initially, I thought it's going to be easy but I spent quite a while trying to figure it out (and still haven't).

The AppVeyor build failure appears to be for commit 4668c3d - I'm not sure how to prod it to rerun...

Whoops, no - I've found it. I accidentally made a change in csharp_message which I didn't mean to. Will commit the change and regenerated code in a minute.

LGTM, thanks for taking the time to remove protobuf attributes. The solution looks much better now.