This is admittedly a bit of a contrived example, but it does illustrate the issues.

Protocol definition

option c.name_prefix = "c__"; // Note: 2 underlines, lowercase

enum MyEnum : uint8 {
    MY_VALUE = 0;
}

message MyMessage {
    MyEnum member = 1;
}

const MY_CONSTANT = 3;

Generated code

// constants adhere to exact prefix but add an extra "_"
#define c___MY_CONSTANT 3

// enums always convert to PascalCase
typedef uint8_t CMyenum;

// enum fields always convert to SCREAMING_SNAKE_CASE
#define C_MY_VALUE 0

// "BYTES_LENGTH_" always convert to SCREAMING_SNAKE_CASE, prefix ends up mid-name
#define BYTES_LENGTH_C_MYMESSAGE 1

// messages always convert to PascalCase
struct CMymessage {
    // message fields always convert to PascalCase
    CMyenum member;
};

// encode/decode functions always PascalCase, prefix ends up mid-name
int EncodeCMymessage(struct CMymessage *m, unsigned char *s);

I'm not quite settled on how prefixes should apply to "BYTES_LENGTH_" and encode/decode functions:

• If the prefix belongs to the type, it makes sense for it to be applied mid-name (as it is now), though the name-mangling is not intuitive. However without it also getting applied to the start, it breaks the namespace-like pseudo-encapsulation.
• If it belongs to the protocol, it would make sense for it to be placed either at the start (c__EncodeMyMessage()), or both at the start and before the "message name" part to keep in line with the type being referenced (c__Encodec__MyMessage(), as ugly as that is in this particular case).

I don't really see an obvious choice as it depends on the purpose and the exact prefix being used.