See also MDSAL-133.

We have the following augments in a model (https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob;f=mappingservice/lisp-proto/src/main/yang/odl-lisp-address-types.yang;h=2637ebc222fb6b58eb907b2fd6f346ca1a7e3c37;hb=HEAD):

grouping augmented-lisp-address {
uses laddr:lisp-address {
augment "address" {
leaf ipv4-binary {
when "../../address-type = 'ipv4-binary-afi'"

type bin:ipv4-address-binary;
description
"IPv4 (binary) address.";
}
leaf ipv6-binary {
when "../../address-type = 'ipv6-binary-afi'"

type bin:ipv6-address-binary;
description
"IPv6 (binary) address.";
}
}
}
}

The "address" that is augmented is a choice, that doesn't have 'case' statements.

The yangtools generated Ipv

BinaryBuilder object can't set or get the leaf either. Looking at the comment at the top of the auto-generated Java classes, and comparing it to the non-augmented counterparts reveals that the latter seem to add a 'case' statement to the YANG snippet, even if the original model doesn't have it. Manually adding a 'case' to the above augment solves the problem, and getters/setters become available.