You can handle missing values if you plan for it when you design the API. As the article says you can use the well-known optional types, or now mark fields as optional.

Protocol buffers include a set of rules to follow for backwards and forwards compatibility between servers and clients, I think these should be understood as part of the philosophy of protocol buffers. https://protobuf.dev/programming-guides/proto3/#updating

> Imagine building a data format for temperature measuring stations around that. Is it 0 degrees, or did the thermometer just skip reporting?

What does it mean for a thermometer to "skip reporting"? If that is something you intend to support you will need to define what it means and how the data should be read. Should a reader always check if the field is present? Should it crash?

What would typically happen is that you start out with a required field, because of course you will always have a temperature:

  required sint32 temperature = 1; // temperature in Fahrenheit

But soon enough you realize you need a richer format.

  required sint32 legacy_temperature = 1 [deprecated=true]; // temperature in Fahrenheit - DO NOT USE
  message Measurement { 
    optional Unit unit = 1;
    optional float value = 2;
  }
  optional Measurement temperature = 2;

- or you decide to allow submitting a batch of temperatures in each message, etc.

You configure new measurement stations to set both the old and the new format so they'll be compatible with old servers - maybe your customers are running servers on-prem. You mark legacy_temperature as optional in your server code to prepare for eventual deprecation (luckily in this case the server never sends temperatures back to measuring stations)

Finally all the customers have upgrade to the new server, and you ship new stations that don't set the previously "required" field. New measurement stations don't show up in the UI. A batch job that doesn't even look at the temperature field was compiled with the old definitions and is now crashing.