`change $Obj (Assoc = $Other)` on a ReferenceSet stores it as an Attribute, corrupting the project (`StorageLoadException`)

[MendixMau]

Solution exists in fork: engalar/mxcli fixed this in commit 371fe1cb6 (2026-05-21,
"fix(microflow): association member in change action stored as Attribute instead of
Association"). Root cause and fix are well isolated — see below.

Environment: mxcli (RnD/upstream), Mendix 11.12.0 project.

Steps to reproduce:

create module ZZB;
/
create microflow ZZB.ACT_R01 ()
returns Boolean as $Result
begin
  declare $Result boolean = false;

  retrieve $Role from System.UserRole
    where "Name" = 'User'
    limit 1;

  $Acc = create Administration.Account (
    "Name" = 'zzb_r01_user',
    "Password" = 'ZzB#R01Pass!',
    "Active" = true);

  change $Acc (System.User_UserRoles = $Role);

  commit $Acc with events;

  set $Result = true;
  return $Result;
end;

Run mxcli exec script.mdl -p project.mpr, then try to open/load the resulting .mpr (or run
mx check).

Expected behavior: Assigning a ReferenceSet association (System.User_UserRoles) from a
change action should store it in the BSON Association field, and the project should remain
loadable.

Actual behavior: mxcli exec reports success (Created module, Created microflow) with
no warning — the corruption is invisible at write time. The project subsequently fails to load
at all:

Mendix.MxToolset.Convert.MprHandler.TryLoadMpr(...)
Mendix.Modeler.Storage.Mpr.Storage.MprStorageManager.Do[T](...)
  → StorageLoadException

BSON inspection shows the underlying cause: "not a valid AttributeIdentifier" — the
association got written into the Attribute field instead of Association.

Root cause (per the fork's fix): the change-action member classifier
(resolveMemberChangeGenStandalone) decided attribute-vs-association using
strings.Contains(memberName, "."). A one-dot association name (System.User_UserRoles)
satisfies that check exactly like an attribute reference would, so it's written to the wrong
BSON field — which Studio Pro rejects at load time. This is compounded by mxcli writing
associations before microflows without invalidating the association-lookup cache in between,
so the classifier sees a stale, empty association list and falls through to the buggy
dot-counting heuristic.

Suggested fix: require ≥2 dots before treating a member name as an attribute (a one-dot
name is always a module-qualified association/entity reference, never an attribute path), or
port the fork's dedicated memberChangeFallback() classifier.