+1
I would also appreciate support for optional fields in ROS2. The best use case I can currently think of is to get rid of the geometry_msgs/FooWithCovariance message types and merge them into one geometry_msgs/Foo message with an optional covariance field (not considering backwards compatibility in this case). A node that is only interested in the actual value and not in the covariance information would not need to implement different subscribers for the two types or apply shape shifting. Other tools like rviz could optionally visualize the covariance, if available.
In general, having native optional field support in many cases removes the need to define different, but very similar messages and - depending on how the presence of optional fields is encoded in the wire format - can also help to reduce wire size because unavailable data does not have to be represented by a full 8-byte NaN double.
Protobuf 2 also has optional (an required) fields, but apparently this feature has been removed in Protobuf 3 for a good reason…