Function default_acl_for_create 

pub fn default_acl_for_create(
    declared: &ParseValue,
    caller: Option<&str>,
) -> ParseValue

Resolve a class’s declared default ACL into the value a create should carry.

RestWrite.js:385-391. The declared block is copied, and if it names currentUser then the caller’s objectId gains a copy of that entry and the currentUser key is removed.

Three details are load-bearing and each fails silently if it is got wrong.

currentUser is resolved, never stored. An ACL containing the literal string currentUser as a principal matches nobody, so the row is unreadable by everyone including the user it was meant for, and the configuration reads as though it worked.

An anonymous caller loses the entry rather than keeping it. Upstream’s delete is outside the if (this.auth.user?.id) guard, so with no caller there is no substitute id and the key simply goes. A class whose only declared entry is currentUser therefore produces an ACL with no entries at all for an anonymous create, which is a row only master can read. That is upstream’s behavior and it is the restrictive direction.

Key order is preserved, and it is not upstream’s order. The _rperm and _wperm arrays are built by walking the ACL, so their element order comes from here, and a mixed fleet compares stored rows. Substituting the caller’s id in place of currentUser rather than appending would reorder them, so the substitution appends as upstream’s assignment does.

That is where the resemblance stops. Upstream enumerates a JavaScript object, so an integer-like key sorts ahead of every string key regardless of insertion order, and an objectId of 1234567890 is integer-like. parse-rust preserves wire order throughout, so the stored arrays differ for any ACL naming such a principal. Measured, and not fixed here: it has no authorization consequence and the fix belongs in lower_acl with the array case.