On several STARs, procedure altitude constraints are not appearing on the FMS legs at all. On the LEGS/CDU page the coded constraint is absent, and the FMS substitutes its own computed altitude. Because the constraint never reaches the leg, no valid descent path builds and the aircraft arrives at the approach transition well above profile without manual intervention.

The key finding: this is not the path builder mis-applying a constraint it has. The constraint is missing from the leg entirely. This points at procedure-leg ingestion / altitude-descriptor decoding rather than the descent math.

Primary example — LFMN, BORD8R arrival (Navigraph)

BORDI — coded FL170 (B). On the LEGS page no constraint is displayed at all — the field shows only the FMS-computed FL300. The FL170 crossing is absent, not merely mis-computed.
MIRKU — coded FL110 (at or above) → downstream at OTOKE the FMS computes FL112, i.e. above the MIRKU floor and on a later fix. Consistent with the path being anchored to whatever sparse constraints survive ingestion (MIRKU) after the ones above it (BORDI) have been dropped.
Consequence: by NERAS, ahead of the approach fixes, the aircraft is far too high to recover the profile without manual intervention.

Because BORDI's constraint is entirely absent from the leg — rather than present-but-wrong — I suspect certain altitude descriptors (ARINC 424 @ / + / - / "B") or certain constraint codings on these procedures are failing to decode and being discarded during ingestion, rather than being mishandled later by the VNAV path builder.

Other airports showing the same pattern

EHAM (Amsterdam)
LSZH (Zürich)
LFMN (Nice) — numerous; BORD8R and other arrivals

All terrain/airspace-constrained STARs with stacked step-downs (mixed hard crossings and at-or-above floors), which likely explains why the issue surfaces here and stays hidden on simpler "cross at" STARs.

What I've checked

Nav data: Navigraph, current cycle.
On the LEGS page, BORDI displays no altitude constraint at all — only the computed FL300 descent. The coded FL170 is absent from the leg. (This is the finding that points to ingestion/decoding rather than the path builder.)
Manually typing FL170 into BORDI's altitude field does then produce a correct path. — if a manually entered constraint is honored while the coded one is dropped, that confirms the decode/ingestion path as the culprit rather than the VNAV math. Worth a quick test before sending.]

Suspected area

Procedure-leg ingestion / altitude-constraint decoding: certain coded constraints (suspected: specific altitude descriptors, or the "at"/hard-crossing type on these STARs) are being dropped rather than attached to their legs. Downstream, the VNAV path builds from only the surviving constraints, producing the observed high path. Expected behavior: every coded constraint attaches to its leg with its correct descriptor (floor / ceiling / hard / block), and the path is built backward from the most-binding downstream constraint with the intermediate ones applied as checks.

Just wanted to add it to the list of examples where the FMS is not respecting STARs and SIDs. Nonetheless love the plane but hope this helps in your resolution of these challenges - thanks for all your work!