marketplace update --save-edits + exec corrupts constant folder paths containing a literal '/' in the folder name #1367

Summary

When a Constant's folder (in its Studio Pro folder tree) has a display name that itself contains a literal / character, mxcli marketplace update ... --save-edits <dir> serializes that folder into a flat MDL folder '...' string using / as the path separator, with no escaping of a literal / inside a single folder's own name. When that saved .mdl file is later replayed with mxcli exec, the parser treats every / as a folder boundary, splitting the original single folder into multiple nested folders. The constant ends up moved to a different (wrong, deeper) location in the tree.

Steps to reproduce

1. In Studio Pro, create a folder named with a literal / in its name, e.g. Private - String en/de-cryption, and inside it a child folder Apis.
2. Place a module Constant (e.g. from a Marketplace module like the Encryption module's EncryptionKey) inside that Apis folder.
3. Run:

   mxcli.exe marketplace update <contentId> -p <App.mpr> --to <newVersion> --module <ModuleName> --save-edits <editsDir> --force
   

4. Inspect <editsDir>\constant-EncryptionKey.mdl. It contains:

   folder 'Private - String en/de-cryption/Apis'
   

   -- the folder's own / has been flattened indistinguishably from a path separator.
5. Run:

   mxcli.exe exec -p <App.mpr> <editsDir>\constant-EncryptionKey.mdl
   

6. Open the app in Studio Pro. The constant is no longer in one folder named Private - String en/de-cryption containing Apis. Instead it's nested three levels deep: Private - String en -> de-cryption -> Apis -- three separate folders were created/used instead of one.

Expected behavior

The constant should end up back in its original single folder Private - String en/de-cryption -> Apis, unchanged by the update/re-apply round trip.

Actual behavior

The folder hierarchy is corrupted: a literal / in a folder's own name is misinterpreted as a nesting separator, both when --save-edits serializes the folder path and when exec parses it back, producing extra spurious folder levels.

Root cause (as far as we can tell from the outside)

The MDL folder '...' clause's string format appears to use / as the only delimiter for nested folder paths, with no escape sequence (e.g. no \/ or quoting-per-segment) for a literal / inside one folder's display name. This makes the format fundamentally ambiguous for any folder name containing / -- serialization (--save-edits) and parsing (exec) both need a fix, since either one alone can't fully solve it without a defined escaping convention.

Suggested fix

Either:

• Escape literal / characters within a single folder-name segment when writing the folder '...' value in --save-edits output, and unescape them in exec's parser (e.g. \/), or
• Change the serialization to use an unambiguous separator/structure (e.g. a JSON array of folder-name segments, or a separator character disallowed in Mendix folder names) instead of plain /-joined strings.

Impact

Any Constant (and potentially other model elements whose --save-edits output includes a folder '...' clause) whose containing folder name legitimately contains / will have its folder silently corrupted every time update/save-edits/exec round trips are performed. This is silent -- mxcli exec exits 0 and gives no indication the folder structure changed in an unintended way.

Environment

• Observed via a local automation pipeline that calls mxcli.exe marketplace update ... --save-edits followed by mxcli.exe exec to reapply saved constant edits after a module update, as part of a Mendix model version upgrade originally from 10.7.0 -> (bridge 10.24.26 -> 11.12.6).
• Affected module: Encryption Marketplace module, EncryptionKey constant.

Version

mxcli version v0.25.0 (2026-10-05T09:18:28Z)