Well there are a couple of workarounds for this if I understood well the changelog (It applies only to primitives) I did this on the fly so forgive me if there's something wrong. Both approaches are annoying anyway.

a) you can specify a null indicator like in the good ol' days.

bool secondNameIndicator = 1
String secondName = 2

Then you can set it...

setSecondName("John"); AND setSecondNameIndicator(true);

... check it ...

if (getSecondNameIndicator())

... get it ...

getSecondName();

b) This applies only to primitives so there's really nothing stopping you from doing

message Person {
optional string name = 1;

message SecondName {
optional string value = 1;
}
optional SecondName value = 2;
}

and then you can set it...

person.setSecondName(Person.SecondName.newBuilder().setValue("Jr"));

...check it (This works with non-primitives normally)...

if (person.hasSecondName())

... get it ...

person.getSecondName().getValue()

If you need the field presence info for primitive fields, there will be "well known types" protos introduced in 3.0 beta releases, which includes built-in wrapper types. e.g.

message IntegerValue {
  optional int32 value = 1;
} 

then you can write

message MyMessage {
  optional int32 field1 = 1;
  optional IntegerValue field2 = 2;
}

This is aligned with native languages (like Java). You can have

class MyMessage {
  public int field1;
  public Integer field2;
}

There's no field presence info for field1, but there is for field2, where you can set it to null.