You don’t conflate framing with payload by emitting invalid non-standard framed data from a “protobuf” encoder. They’re separate concerns and need to remain that way.
The result is not protobuf and doesn’t claim to be.
Looking at my employer’s protobuf runtime for our major programming language, we don’t even support it.
If your implementation doesn't support something in the reference implementation, that seems like your problem, not anyone else's.
[1] https://protobuf.dev/reference/csharp/api-docs/class/google/...
Because it’s not part of the protobuf specification, not part of a valid protobuf message, and framing is a transport/file format concern and should not be performed by default.
If someone is expecting to receive a protobuf-encoded payload, it must not include a framing header.
> If your implementation doesn't support something in the reference implementation, that seems like your problem, not anyone else's.
Someone else’s failure to follow the spec is not our problem.
https://protobuf.dev/reference/csharp/api-docs/class/google/...
> you skip the "helper" function that's breaking things.
Yea ok, I'm just going to assume this helper function added framing unless told otherwise. Where in this post did you even read that framing and payload data were conflated (not to mention that there are better protocols that include framing metadata).