Bug: SPLIT TYPE layout stacks the ExclusiveMerge and EndEvent at the same position (v0.19.0)

[MohamedGamalEzzatAli]

Bug: SPLIT TYPE layout stacks the ExclusiveMerge and EndEvent at the same position (v0.19.0)

Summary

Since the v0.19.0 type-split restructuring (#913), a microflow authored with SPLIT TYPE … END SPLIT followed by more statements places the generated ExclusiveMerge and the following
element at the exact same RelativeMiddlePoint — the end event renders on top of the merge
in Studio Pro, connected by a zero-length sequence flow. CASE (enum split) and IF/ELSE
with the identical graph shape lay out correctly, so this is specific to the SPLIT TYPE
layout path.

Environment

• mxcli v0.19.0 (b313ff0), Windows amd64
• Mendix 11.12.1 project, MPRv2 (mprcontents/)

Minimal reproduction

CREATE MODULE Repro;

CREATE PERSISTENT ENTITY Repro.Animal (
  Name: String(100)
);

CREATE PERSISTENT ENTITY Repro.Dog EXTENDS Repro.Animal (
  Breed: String(100)
);

CREATE MICROFLOW Repro.SUB_KindOf (
  $Animal: Repro.Animal
)
RETURNS String AS $Kind
BEGIN
  DECLARE $Kind String = '';
  SPLIT TYPE $Animal
    WHEN Repro.Dog THEN
      SET $Kind = 'dog';
    WHEN Repro.Animal THEN
      SET $Kind = 'animal';
    WHEN (empty) THEN
      SET $Kind = 'none';
  END SPLIT;
  RETURN $Kind;
END;

mxcli check --references passes and exec succeeds. The defect is geometry only — the
graph itself (InheritanceSplit, three branches, merge, end) is correct.

Observed (coordinates read from the stored unit BSON, RelativeMiddlePoint / Size)

Repro.SUB_KindOf (SPLIT TYPE) — broken:
  1480;200  40x40  ExclusiveMerge
  1480;200  20x20  EndEvent        <-- fully inside the merge, zero-length flow between them

The same shape through the enum split lays out correctly, which isolates the defect to the
SPLIT TYPE path:

CREATE MICROFLOW Repro.SUB_EnumCase ($C: Repro.Color) RETURNS String AS $Out
BEGIN
  DECLARE $Out String = '';
  CASE $C
    WHEN Red THEN SET $Out = 'r';
    WHEN Green THEN SET $Out = 'g';
    WHEN (empty) THEN SET $Out = 'e';
  END CASE;
  RETURN $Out;
END;

Repro.SUB_EnumCase (CASE) — correct:
  890;200   40x40  ExclusiveMerge
  970;200   20x20  EndEvent        <-- healthy 80px x-advance after the merge

Two more data points that may help locate it:

• IF/ELSE with SET branches and a shared RETURN also lays out correctly.
• The SPLIT TYPE flow's merge x looks over-advanced relative to its branches
  (branch activities at x=720, merge at x=1480 — the CASE flow's merge sits at 890 for the
  same shape), so the type-split layout path seems to both over-advance x for the merge and
  then not advance it after the merge. The two errors together land the next element exactly
  on the merge.

Expected

The element following END SPLIT is placed after the merge with the normal horizontal
spacing, as the CASE and IF/ELSE layout paths already do.

Impact

Every SPLIT TYPE authored under the new v0.19 grammar ships a diagram where the end event
(or whatever follows the split) is hidden underneath the merge — mx check is clean, so
nothing flags it until a human opens the flow in Studio Pro.