This really is a question on what isMandatory() reflects. Historically it reflected the presence of a mandatory statement, e.g. the declared model of the world.

Making it reflect the reality of effective world is problematic, as it is not a static property, consider e.g.:

grouping grp {
leaf foo

}

leaf bar

container baz {
uses grp

}

Yep, anyway, when "mandatory" meets "when", it's not clear and confusing what mandatory does reflect.
In RFC it said "If a key leaf is defined in a grouping that is used in a list, the"uses" statement MUST NOT have a "when" statement."
and that may be suitable for a mandatory node just like
"If a mandatory node is defined in a grouping, the"uses" statement MUST NOT have a "when" statement."

Ah, I see, I missed those bits.

Incidentally I came across isMandatory() just yesterday during the push to cleanup yang-model-api and it still is on my plate.

In the end, I think isMandatory() should reflect whether or not a node is effectively mandatory, if it can be proven to be static property and if we can get users working (yang-model-export may need a major update to work completely on the declared model anyway, but there may be others0.

Actually that will not completely work, either. Even if we expand the scope of that uses restriction to cover mandatory nodes, it does not solve augmentations, which may explicitly add mandatory nodes only when guarded by a when conditions:

module foo:
container foo { }

module bar:
import foo

;
leaf bar

augment /foo:foo {
leaf baz

when "../bar";
}

This case is specifically called out in RFC7950, hence isMandatory() cannot be made a static property, because the intepretation of augment applicability (and hence the decision whether /foo is mandatory) depends on the data being processed.

I will add a comment to this effect.

I also found this in RFC7950 (Section 8.1):
"The "mandatory" constraint is enforced for leafs and choices,
unless the node or any of its ancestors has a "when" condition or
"if-feature" expression that evaluates to "false"."
So maybe we could just divide it into two parts:
1) DO NOT has a "when" condition
All ancestors(here non-presence container specifed explicitly, not grouping or others) of a mandatory node should be made a static property;
2) Has a "when" condition

• Uses with a "when" condition, all ancestors of uses node would not be made the static property;
• Augment with a "when" condition, all ancestors of target node would not be made the static property;

In RFC7950 (Section 7.17):
"If the augmentation adds mandatory nodes (see Section 3) that
represent configuration to a target node in another module, the
augmentation MUST be made conditional with a "when" statement. "

Well, I guess the primary question is what use case do we have for such a flag. isMandatory() certainly is going away from ConstraintDefinition (as that entire interface needs to go), hence isMandatory() will not be emitted for containers at all (only leaf/choice/anydata/anyxml will have it).

Since ConstraintDefinition has been eliminated, isMandatory() reflects the value of 'mandatory' statement only, making the definition consistent.